InnoDB 在您使用 SQL 陳述式刪除列時，不會立即從資料庫中實體移除列。只有當 InnoDB 捨棄為刪除寫入的復原日誌記錄時，才會實體移除列及其索引記錄。此移除操作僅在多版本並行控制 (MVCC) 或回滾不再需要該列時才會發生，稱為清理。

清理會定期執行。它會剖析並處理來自歷史清單的復原日誌頁面，該歷史清單是 InnoDB 交易系統維護的已提交交易的復原日誌頁面清單。清理會在處理完復原日誌頁面後將其從歷史清單中釋放。

配置清理執行緒

清理操作由一個或多個清理執行緒在背景中執行。清理執行緒的數量由 innodb_purge_threads 變數控制。如果可用的邏輯處理器數量 <= 16，則預設值為 1，否則預設值為 4。

如果 DML 動作集中在單個資料表上，則該資料表的清理操作由單個清理執行緒執行，這可能會導致清理操作變慢、清理延遲增加，以及如果 DML 操作涉及大型物件值，則表格空間檔案大小增加。如果超過 innodb_max_purge_lag 設定，則清理工作會自動在可用的清理執行緒之間重新分配。在這種情況下，過多的活動清理執行緒可能會導致與使用者執行緒的競爭，因此請相應地管理 innodb_purge_threads 設定。innodb_max_purge_lag 變數預設設定為 0，這表示預設情況下沒有最大清理延遲。

如果 DML 操作集中在少數幾個資料表上，請保持 innodb_purge_threads 設定為較低的值，以避免執行緒之間為了存取忙碌的資料表而產生競爭。如果 DML 操作分散在許多資料表上，則考慮使用較高的 innodb_purge_threads 設定。清除執行緒的最大數量為 32。

innodb_purge_threads 設定是允許的最大清除執行緒數量。清除系統會自動調整所使用的清除執行緒數量。

設定清除批次大小

innodb_purge_batch_size 變數定義了清除作業在單一批次中從歷史記錄清單解析和處理的 undo log 頁面數量。預設值為 300。在多執行緒清除組態中，協調器清除執行緒會將 innodb_purge_batch_size 除以 innodb_purge_threads，並將該數量的頁面分配給每個清除執行緒。

清除系統也會釋放不再需要的 undo log 頁面。它會每 128 次迭代遍歷 undo log 時執行此操作。除了定義單一批次中解析和處理的 undo log 頁面數量之外，innodb_purge_batch_size 變數還定義了清除作業每 128 次迭代遍歷 undo log 時釋放的 undo log 頁面數量。

innodb_purge_batch_size 變數適用於進階效能調整和實驗。大多數使用者無需將 innodb_purge_batch_size 從其預設值更改。

設定最大清除延遲

innodb_max_purge_lag 變數定義了期望的最大清除延遲。當清除延遲超過 innodb_max_purge_lag 閾值時，會對 INSERT、UPDATE 和 DELETE 操作施加延遲，以便讓清除操作有時間趕上。預設值為 0，這表示沒有最大清除延遲，也沒有延遲。

InnoDB 交易系統會維護一份交易清單，其中包含已被 UPDATE 或 DELETE 操作標記為刪除的索引記錄。該清單的長度即為清除延遲。

清除延遲的計算公式如下

(purge_lag/innodb_max_purge_lag - 0.9995) * 10000

延遲是在清除批次開始時計算的。

對於有問題的工作負載，innodb_max_purge_lag 的典型設定可能是 1000000 (一百萬)，假設交易很小，只有 100 個位元組大小，且允許存在 100MB 的未清除資料表列。

清除延遲以 SHOW ENGINE INNODB STATUS 輸出的 TRANSACTIONS 區段中的 History list length 值表示。

mysql> SHOW ENGINE INNODB STATUS;
...
------------
TRANSACTIONS
------------
Trx id counter 0 290328385
Purge done for trx's n:o < 0 290315608 undo n:o < 0 17
History list length 20

History list length 通常是一個較低的值，通常小於幾千，但寫入密集型工作負載或長時間執行的交易可能會導致它增加，即使對於僅讀取的交易也是如此。長時間執行的交易可能導致 History list length 增加的原因是，在一致讀取交易隔離層級（例如 REPEATABLE READ）下，交易必須傳回與該交易的讀取檢視建立時相同的結果。因此，InnoDB 多版本並行控制 (MVCC) 系統必須在所有依賴該資料的交易完成之前，在 undo log 中保留一份資料複本。以下是可能導致 History list length 增加的長時間執行交易的範例

為了防止在清除延遲變得巨大時出現極端情況下的過度延遲，您可以設定 innodb_max_purge_lag_delay 變數來限制延遲。innodb_max_purge_lag_delay 變數指定了當超過 innodb_max_purge_lag 閾值時所施加延遲的最大微秒數。指定的 innodb_max_purge_lag_delay 值是 innodb_max_purge_lag 公式計算出的延遲期間上限。

清除和 Undo 表空間截斷

清除系統也負責截斷 undo 表空間。您可以設定 innodb_purge_rseg_truncate_frequency 變數來控制清除系統尋找要截斷的 undo 表空間的頻率。有關更多資訊，請參閱截斷 Undo 表空間。