MySQL purge 線程

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線程将上述實驗中被删除資料部分對應的磁盤空間标記為可用，可以被後續寫入操作使用，這樣就不用再次配置設定磁盤空間了)。

本文轉自 lirulei90 51CTO部落格，原文連結：http://blog.51cto.com/lee90/1974179，如需轉載請自行聯系原作者