MySQL中的I/任務很多，比如 從buffer pool flush 髒頁去磁碟，或者是merge change buffer中的內容到二級索引，InnoDB也一直在做著IO相關的最佳化工作，今天從IO引數入手，去學習IO相關的內容吧!

IO相關

1.Configuring InnoDB I/O Capacity

1.1 innodb_io_capacity

預設值200，最小100，最大2的64次方-1，是所有buffer_pool_instance的設定，當flush發生的時候，capacity被平均到每個instance上。defines the number of I/O operations per second (IOPS) available to InnoDB background tasks，這個引數設定的話，一些後臺任務的調整可能會依據你設定的值來作為參考了。設定太高也不好，會讓buffer pool的效果更差。設定太低，則影響效能，主要還是看自己的磁碟效能，設定一個合理的值，一般超過2w就不推薦了。

1.2 innodb_flush_sync

預設開啟，這個引數在checkpoint時如果有大量的IO發生是會忽略掉innodb_io_capacity的設定的，注意這點。

1.3 innodb_io_capacity_max

如果沒有設定innodb_io_capacity_max那麼它的值初始化的時候會被定義為 max(innodb_io_capacity *2 ,2000)

2.Configuring Buffer Pool Flushing

2.1 innodb_page_cleaners

預設為4，如果設定的值超過了buffer pool instance的個數，則自動設定為和buffer pool instance 相同數值。

2.2 innodb_max_dirty_pages_pct_lwm

The default low water mark is 10% of buffer pool pages. A innodb_max_dirty_pages_pct_lwm value of 0 disables this early flushing behaviour.

2.3 innodb_max_dirty_pages_pct

髒頁最大比例，預設90%

2.4 innodb_flush_neighbors

0 表示不刷相同區內的鄰近髒頁，1表示刷相同區的鄰近髒頁，2表示刷相同區的所有髒頁。

2.5 innodb_lru_scan_depth

how far down the buffer pool LRU list the page cleaner thread scans looking for dirty pages to flush.如果是寫密集型應用且IO接近飽和，那麼應該減小這個值。一般挑戰了buffer pool大小之後都建議調整這個值，innodb_lru_scan_depth * innodb_buffer_pool_instances決定page cleaning執行緒每秒的工作量。

2.6 innodb_adaptive_flushing_lwm

這個值定義了redo log容量的低水位，當超過這個值adaptive flushing就會開啟，即使 innodb_adaptive_flushing是關閉的。

2.7 innodb_adaptive_flushing

adaptive flushing演算法預設開啟，主要為了保證redo log不會滿。

2.8 innodb_flushing_avg_loops

預設30，1-1000，Number of iterations for which InnoDB keeps the previously calculated snapshot of the flushing state, controlling how quickly adaptive flushing responds to changing workloads.根據之前flush狀態的計算快照來進行的迭代次數，調高則頻率調整的更平滑，調低則頻率調整的更激進。如果redo log檔案空間較大，很少有尖刺會到達75%的容量，那麼可以增加這個值，讓調整更加平滑。

2.9 innodb_idle_flush_pct

8.0.18之後可以定義這個值，它是innodb_io_capacity的比值，預設是100%，限制空閒時間刷buffer pool的比例，設定這個比例小於100%可以延長SSD壽命，但是也有副作用，限制空閒時間刷髒頁的比例會導致一個長時間空閒之後的crash的恢復時間較長以及一個較長時間的shutdown。

3.Purge Configuration

purge 什麼叫purge呢?就是刪除資料不會立馬被刪除而是被打上標記，等後面MVCC不需要對應的undo的時候，這個記錄就可以被物理刪除了，這個過程叫purge。

3.1innodb_purge_threads

預設為4.最大32，當DML發生的表比較少，則這個值不要設定太大，會產生衝突;DML併發操作的表比較多，那麼可以調大這個值。這個值只是一個最大值，系統會自動調整。

3.2 innodb_max_purge_lag

預設為0，8.0.26引入。如果DML操作單張表，那麼只有一個thread會進行purge操作，導致purge比較慢，產生purge lag，並且如果事務涉及到的行比較多的話，還會增加表空間大小，這個時候如果超過了lag的大小，那麼purge任務則會被自動的分佈到可用的thread上，過多的活躍清理執行緒會和使用者執行緒產生衝突，所以要根據實際情況進行這個引數的調整。

3.3 innodb_purge_batch_size

定義了每批處理history list中undo 頁面的個數，預設是300.平均分到每個執行緒上進行處理。清理執行緒也會清理不需要的undo log 頁面，128次迭代之後會進行清理，這個值也會定義每次清理的undo 頁面數量。

3.4 innodb_max_purge_lag

預設是0，當這個lag到達閾值，DML操作將會延遲，直到lag被追上。innodb事務維護了一張有標記為刪除的索引記錄列表，這張表的長度就是purge lag，在8.0.14之前，purge lag的延遲是透過(purge lag/innodb_max_purge_lag - 0.5) * 10000這個公式計算的，這會導致最少5000微妙的延遲，8.014的之後透過(purge_lag/innodb_max_purge_lag - 0.9995) * 10000來計算，

這樣最小延遲5微秒。

3.5 innodb_max_purge_lag_delay

定義了超過 innodb_max_purge_lag之後最大的延遲(微秒)。

3.6 innodb_purge_rseg_truncate_frequency

清理執行緒檢查truncate tablespace的頻率，預設值128，the number of times that purge is invoked.