**背景** 關于Group Commit網上的資料其實已經足夠多了，我這里只簡單的介紹一下。 眾所周知，在MySQL5.6之前的版本，由于引入了Binlog/InnoDB的XA，Binlog的寫入和InnoDB commit完全串行化執行，大概的執行序列如下： ~~~ InnoDB prepare （持有prepare_commit_mutex）； write/sync Binlog； InnoDB commit (寫入COMMIT標記后釋放prepare_commit_mutex)。 ~~~ 當sync_binlog=1時，很明顯上述的第二步會成為瓶頸，而且還是持有全局大鎖，這也是為什么性能會急劇下降。 很快Mariadb就提出了一個Binlog Group Commit方案，即在準備寫入Binlog時，維持一個隊列，最早進入隊列的是leader，后來的是follower，leader為搜集到的隊列中的線程依次寫Binlog文件, 并commit事務。Percona 的Group Commit實現也是Port自Mariadb。不過仍在使用Percona Server5.5的朋友需要注意，該Group Commit實現可能破壞掉Semisync的行為，感興趣的點擊?[bug#1254571](https://bugs.launchpad.net/percona-server/5.5/+bug/1254571) Oracle MySQL 在5.6版本開始也支持Binlog Group Commit，使用了和Mariadb類似的思路，但將Group Commit的過程拆分成了三個階段：flush stage 將各個線程的binlog從cache寫到文件中; sync stage 對binlog做fsync操作（如果需要的話）；commit stage 為各個線程做引擎層的事務commit。每個stage同時只有一個線程在操作。 Tips：當引入Group Commit后，sync_binlog的含義就變了，假定設為1000，表示的不是1000個事務后做一次fsync，而是1000個事務組。 Oracle MySQL的實現的優勢在于三個階段可以并發執行，從而提升效率。更進一步的理解，可以參考[這篇博客](http://mysqlmusings.blogspot.com/2012/06/binary-log-group-commit-in-mysql-56.html) **XA Recover** 在Binlog打開的情況下，MySQL默認使用MYSQL_BIN_LOG來做XA協調者，大致流程為： ~~~ 1.掃描最后一個Binlog文件，提取其中的xid； 2.InnoDB維持了狀態為Prepare的事務鏈表，將這些事務的xid和Binlog中記錄的xid做比較，如果在Binlog中存在，則提交，否則回滾事務。 ~~~ 通過這種方式，可以讓InnoDB和Binlog中的事務狀態保持一致。顯然只要事務在InnoDB層完成了Prepare，并且寫入了Binlog，就可以從崩潰中恢復事務，這意味著我們無需在InnoDB commit時顯式的write/fsync redo log。 Tips：MySQL為何只需要掃描最后一個Binlog文件呢 ？ 原因是每次在rotate到新的Binlog文件時，總是保證沒有正在提交的事務，然后fsync一次InnoDB的redo log。這樣就可以保證老的Binlog文件中的事務在InnoDB總是提交的。 **問題** 其實問題很簡單：每個事務都要保證其Prepare的事務被write/fsync到redo log文件。盡管某個事務可能會幫助其他事務完成redo 寫入，但這種行為是隨機的，并且依然會產生明顯的log_sys->mutex開銷。 **優化** 從XA恢復的邏輯我們可以知道，只要保證InnoDB Prepare的redo日志在寫Binlog前完成write/sync即可。因此我們對Group Commit的第一個stage的邏輯做了些許修改，大概描述如下： ~~~ Step1\. InnoDB Prepare，記錄當前的LSN到thd中； Step2\. 進入Group Commit的flush stage；Leader搜集隊列，同時算出隊列中最大的LSN。 Step3\. 將InnoDB的redo log write/fsync到指定的LSN Step4\. 寫Binlog并進行隨后的工作(sync Binlog, InnoDB commit , etc) ~~~ 通過延遲寫redo log的方式，顯式的為redo log做了一次組寫入，并減少了log_sys->mutex的競爭。 目前官方MySQL已經根據我們report的bug#73202鎖提供的思路，對5.7.6的代碼進行了優化，對應的Release Note如下： ~~~ When using InnoDB with binary logging enabled, concurrent transactions written in the InnoDB redo log are now grouped together before synchronizing to disk when innodb_flush_log_at_trx_commit is set to 1, which reduces the amount of synchronization operations. This can lead to improved performance. ~~~ **性能數據** 簡單測試了下，使用sysbench, update_non_index.lua, 100張表，每張10w行記錄，innodb_flush_log_at_trx_commit=2, sync_binlog=1000，關閉Gtid ~~~ 并發線程 原生 修改后 32 25600 27000 64 30000 35000 128 33000 39000 256 29800 38000 ~~~