IO性能瓶頸優化--組送出

二階段送出

二階段送出步驟

1、更新操作記錄到 redo log 裡面，此時 redo log 處于 prepare 狀态。

2、然後告知執行器執行完成了，随時可以送出事務。執行器生成這個操作的 binlog，并把 binlog 寫入磁盤。

3、執行器調用引擎的送出事務接口，引擎把剛剛寫入的 redo log 改成送出（commit）

組送出

我們知道redo的組送出是mysql自己就預設的，在并發更新場景下，第一個事務寫完 redo log buffer 以後，接下來這個 fsync 越晚調用，組員可能越多，節約 IOPS 的效果就越好。

redo的組送出

日志寫到 redo log buffer 是很快的，wirte 到 page cache 也差不多，但是持久化到磁盤的速度就慢多了。讓更多的事務，同時能夠進行fsync就是redo的組送出。

在并發更新場景下，第一個事務寫完 redo log buffer 以後，接下來這個 fsync 越晚調用，組員可能越多，節約 IOPS 的效果就越好。

binlog組送出

在執行圖 中第 4 步把 binlog fsync 到磁盤時，如果有多個事務的 binlog 已經寫完了，也是一起持久化的，這樣也可以減少 IOPS 的消耗。不過通常情況下第 3 步執行得會很快，是以 binlog 的 write 和 fsync

間的間隔時間短，導緻能集合到一起持久化的 binlog 比較少，是以 binlog 的組送出的效果通常不如 redo log 的效果那麼好。

如果你想提升 binlog 組送出的效果，可以通過設定

binlog_group_commit_sync_delay 和

binlog_group_commit_sync_no_delay_count 來實作。

binlog_group_commit_sync_delay 參數，表示延遲多少微秒後才調用 fsync;binlog_group_commit_sync_no_delay_count 參數，表示累積多少次以後才調用 fsync。

WAL 機制優勢

主要得益于兩個方面：

redo log 和 binlog 都是順序寫，磁盤的順序寫比随機寫速度要快；

組送出機制，可以大幅度降低磁盤的 IOPS 消耗。

解決IO性能瓶頸方式

如果你的 MySQL 現在出現了性能瓶頸，而且瓶頸在 IO 上，可以通過哪些方法來提升性能呢？

針對這個問題，可以考慮以下三種方法：

1、設定 binlog_group_commit_sync_delay 和 binlog_group_commit_sync_no_delay_count 參數，減少 binlog 的寫盤次數。這個方法是基于“額外的故意等待”來實作的，是以可能會增加語句的響應時間，但沒有丢失資料的風險。

2、将 sync_binlog 設定為大于 1 的值（比較常見是 100~1000）。這樣做的風險是，主機掉電時會丢 binlog 日志。