文件首頁
MySQL 9.0 參考手冊
相關文件 下載本手冊
PDF (美式信紙) - 40.0Mb
PDF (A4) - 40.1Mb
Man Pages (TGZ) - 258.2Kb
Man Pages (Zip) - 365.3Kb
Info (Gzip) - 4.0Mb
Info (Zip) - 4.0Mb


MySQL 9.0 參考手冊  /  ...  /  清理配置

17.8.9 清理配置

當您使用 SQL 陳述式刪除列時,InnoDB 不會立即從資料庫中實際移除列。只有當 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 變數定義清理在一個批次中從歷史清單剖析和處理的復原日誌頁面數量。預設值為 300。在多執行緒清理配置中,協調器清理執行緒會將 innodb_purge_batch_size 除以 innodb_purge_threads,並將該數量的頁面指派給每個清理執行緒。

清理系統也會釋放不再需要的復原日誌頁面。它會在復原日誌中每 128 次迭代執行一次。除了定義在批次中剖析和處理的復原日誌頁面數量之外,innodb_purge_batch_size 變數還定義清理在復原日誌中每 128 次迭代釋放的復原日誌頁面數量。

innodb_purge_batch_size 變數旨在進行進階效能調整和實驗。大多數使用者不需要將 innodb_purge_batch_size 從其預設值變更。

配置最大清理延遲

變數 innodb_max_purge_lag 定義了期望的最大清除延遲 (purge lag)。當清除延遲超過 innodb_max_purge_lag 閾值時,INSERTUPDATEDELETE 操作會被施加延遲,以便讓清除操作有時間趕上。預設值為 0,表示沒有最大清除延遲,也不會產生延遲。

InnoDB 交易系統維護一個交易列表,其中包含被 UPDATEDELETE 操作標記為刪除的索引記錄。此列表的長度即為清除延遲 (purge lag)。

清除延遲的計算公式如下:

(purge_lag/innodb_max_purge_lag - 0.9995) * 10000

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

對於有問題的工作負載,典型的 innodb_max_purge_lag 設定可能是 1000000 (1 百萬),假設交易很小,大小只有 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) 系統必須在依賴該資料的所有交易完成之前,將資料副本保存在復原日誌中。以下是可能導致 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 公式計算的延遲期間上限。

清除和復原表空間截斷

清除系統也負責截斷復原表空間。您可以設定 innodb_purge_rseg_truncate_frequency 變數來控制清除系統尋找要截斷的復原表空間的頻率。如需更多資訊,請參閱 截斷復原表空間