相關參數
binlog_order_commits— 控制事務的提交順序，1爲和binlog的寫入順序一致，0爲事務並行進行；一般情況下兩者在性能上並沒有明顯差別。
binlog_max_flush_queue_time是指在flush queue裏掃描的時長。
WHY 2PC
Binlog是server層記錄數據改變的日誌，存儲引擎層是最終記錄數據變化的地方，爲了保證複製架構中，主從數據保持一致，就需要做到主庫上binlog中的更新也一定在存儲引擎層被記錄（redo log），同時還需要保證存儲引擎層上的提交順序與binlog中記錄更新的順序保持一致，所以就需要這麼一種提交機制two-phrase commit protocol（2PC）。
在2PC中，通過binlog中是否存在更新的事務來判斷，存儲引擎層的更新是全部提交還是全部回滾；通過prepare_commit_mutex使得事務順序化提交，保證存儲引擎端的commit順序與binlog的寫入順序一致。
Commit Procedure Stages
爲了實現binary log group commit特性，需要將prepare_commit_mutex去除，同時要保證commit順序與binlog write()順序一致，實現方法是將最後一步的commit分成3個階段去完成，即1 st - flush stage、2 nd– sync stage、3 rd– commit stage。
Flush stage— 將需要進行commit操作線程註冊到隊列裏來，對於一個空隊列，先註冊進入的爲leader，之後的爲follower，這些隊列中的線程都已經完成將binlog cache中的跟新寫入（write()）binlog文件（寫入操作系統的文件cache）中。
Sync stage– 根據sync_binlog參數的設置選擇同步（fsync()）binlog 文件到磁盤（“真正”的數據落地，當然磁盤也會有cache，但對於文件系統來說數據已經寫入磁盤已經被持久化）的方式，是one commit 對應one fsync()，還是由文件系統來決定。
Commit stage– 最會由leader按照線程註冊的先後順序，統一去完成每個session下的commit工作。
性能比對
Binary log group commit的實現對於MySQL5.6的性能有了強勁的提升，對於sync_binlog設置爲0與1，隨着併發連接數的不斷增加，兩者的差異越來越不明顯，在起初併發連接數少的情況下，不能發揮group commit的效果，會帶來20%的性能落差。Group commit使得一次commit的事務數增多，即便當sync_binlog爲1時，由於現在一次commit的對象是一個queue，而一個queue裏面包含不止一條要被commit的事務，所以，在參數binlog_max_flush_queue_time觸發之前，當queue中註冊執行commit操作的線程數越多，那麼在sync stage執行fsync()的效率就越高。
學習資源
Binary Log Group Commit in MySQL 5.6這是一篇關於group commit介紹非常細緻的文章以上的文字都是基於對這篇文章的理解，希望大家也來仔細讀一下，說說自己的理解，其實我對於這個東西也沒有完全理解，尤其是flush stage，還有參數 binlog_max_flush_queue_time何時觸發。
深入學習
http://dev.mysql.com/worklog/task/?id=5223
原文轉載於推酷網：http://www.tuicool.com/topics/11030000