MySQL在開啟Binary Log的情況下，使用2PC(圖1)來保證事務(XA)完整性的，每次提交事務需要做: ~~~ 1) prepare phase: 記錄prepare信息到引擎層的Redo Log，fsync到磁盤 2) commit phase: A) 記錄commit信息到MySQL Server層的Binary Log，fsync到磁盤 B) 記錄commit信息到引擎層的Redo Log，fsync到磁盤 ~~~ 每個事務在提交的時候都要做3次fsync以確保日志真正的落盤，這樣在log里，一個事務就會有3種狀態: ~~~ 狀態1: Redo Log里存在，Binary Log里也存在 --正常情況，crash恢復時需要commit 狀態2: Redo Log里存在，Binary Log里不存在 --prepare完畢后發生crash，恢復時需要rollback 狀態3: Redo Log里不存在，Binary Log里也不存在 --提交失敗，無需處理 ~~~ [](http://mysql.taobao.org/index.php?title=%E6%96%87%E4%BB%B6:2pc.png) 這樣，無論處于任何一個狀態，事務的完整性都不會被破壞，但是每次提交會產生3次fsync，性能非常低。? 為了提升性能，MySQL 5.6增加了group commit功能，當多個事務并發提交時，讓多個都在等待fsync的事務合并做一次fsync，大大提升了吞吐量。? 但是這個優化還需要引擎層的配合，引擎層需要＂一切行動聽指揮＂，不要＂任性＂的做fsync，需要對當前THD做HA_IGNORE_DURABILITY判斷，代碼如下: ~~~ static bool tokudb_fsync_on_commit(THD *thd) { #if MYSQL_VERSION_ID >= 50600 if (thd_get_durability_property(thd) == HA_IGNORE_DURABILITY) return false; else #endif return THDVAR(thd, commit_sync)?!= 0; } ~~~ TokuDB 7.5.4版本即將包含這個特性，官方透露，600 tokudb commits/sec只產生120個tokudb fsyncs。