MySQL中purge線程知識：

https://dev.mysql.com/doc/refman/5.7/en/innodb-improved-purge-scheduling.html

InnoDB中delete所做刪除只是標記為刪除的狀態，實際上并沒有刪除掉，因為MVCC機制的存在，要保留之前的版本為并發所使用。最終的刪除由purge線程來決定的什么時候來真正刪除文件的。

purge的處理過程： InnoDB存儲引擎第二版 Page 317 - 318

innodb_purge_batch_size參數：

用來設置每次purge操作需要清理的undo log page的數量。【默認300，表示每次清理300個page，支持動態修改】

設置的越大，表示每次回收的頁也就越多，可供重用的undo page也就越多，就能減少磁盤存儲空間與分配的開銷。不過該參數設置得太大，則每次需要purge處理更多的undo page，從而導致CPU和磁盤IO過于集中于對undo log的處理，使性能下降。普通用戶不建議調整這個參數。

> show VARIABLES like 'innodb_purge_batch%';

+-------------------------+---------+

| Variable_name? ? ? ? ? ?|? ?Value |

|-------------------------+---------|

| innodb_purge_batch_size |? ? ?300 |

+-------------------------+---------+

innodb_purge_threads 參數：

當有很多的表進行DML操作時候， 增大 innodb_purge_threads 能提高purge的效率(清理掉MVCC機制導致的老舊數據)。

現在的MySQL版本中。purge線程已經從master線程中獨立出來,使用單獨的線程提高了可伸縮性。

從MySQL5.7.8開始，這個參數默認是4，最大可以設置為32.【老版本里面這個值默認是1】

innodb_max_purge_lag 參數：

當InnoDB存儲引擎的壓力非常大時，并不能高效地進行purge操作。那么history list(undo log page數量)的長度會變得越來越長。innodb_max_purge_lag 就是控制history list的長度，若長度大于該值，就會延緩DML的操作。該值默認為0，表示不做任何限制。【不建議修改這個參數值!! 】

innodb_max_purge_lag_delay 參數：

表示當上面innodb_max_purge_lag的delay超時時間太大，超過這個參數時，將delay設置為該參數值，防止purge線程操作緩慢導致其他SQL線程長期處于等待狀態。默認為0，一般不用修改。

一個關于刪除數據后磁盤空間再次利用的實驗：

會話1：

use test;

CREATE TABLE `t1` (`a` int(11) NOT NULL AUTO_INCREMENT, `b` int(11) DEFAULT '100', `c` varchar(10) NOT NULL DEFAULT 'cccc', PRIMARY KEY (`a`)) ;

insert into t1 (b,c) select 111,'cccccc';

會話2：

cd /data/mysql/test/

watch -n 1 'ls -lh t1.ibd'

然后再到會話1去多次執行插入數據的操作?insert into t1 (b,c) select b,c from t1 ;? 重復執行多次，可以看到會話2的t1.ibd在不斷在的增大。

假設等到t1.ibd增大到112MB時候，我們到會話1去一個全量的刪除操作delete from t1 where 1=1; 然后少等片刻(等purge線程自動清理數據、master線程將數據落盤)。

這時候去觀察到會話2窗口，可以看到的t1.ibd文件體積一點也沒有減少。

再次到t會話1窗口去執行少量的插入操作，并觀察會話2的t1.ibd文件體積。

可以看到t1.ibd文件的體積沒有再次增長，(原因：purge線程將上述實驗中被刪除數據部分對應的磁盤空間標記為可用，可以被后續寫入操作使用，這樣就不用再次分配磁盤空間了)。