總所周知 ， innodb 的日志是二階段提交的，redolog 先在 prepare 階段寫入， binlog 再寫入，最后 redolog commit
這其中 redolog 的刷入時機是由 innodb_flush_log_at_trx_commit 參數控制，有提交時不刷如，刷入操作系統緩存，落盤 3種操作。
binlog 的刷入時機是由 sync_binlog 參數控制的，設置為 N ，表示每 N 次事務提交 會刷入一次硬盤， 如果設置為 0 只會寫入 os cache
具體的 ，innodb_flush_log_at_trx_commit 參數是在 prepare 控制 這個階段寫入的內容怎么刷硬盤
而 sync_binlog 參數控制的 就是 binlog 在 redolog 之后 的 寫入
值得注意的是， redolog 在 commit 階段是不會刷入硬盤，也不會寫入 os cache，知識單純寫入內存。
因為 如果 binlog 完整， redolog prepare 階段寫入完成，則可以直接把事務提交掉，就算沒有 commit 階段的記錄也行。
redolog 是每執行一條語句都會寫入到 redolog buffer。在某個事務提交的時候一次性組提交，把buffer 所有的內容都刷盤。多個事務共享的是 redolog buffer
binlog 是每個線程都有自己的 binlog buffer， 線程每執行一條語句都會往這里寫，當提交的時候再把 自己的 binlog buffer 寫到 binlog 文件中。多個事務 共享的 是 binlog 文件
另外，innodb 的 redolog 提供了 組提交機制（指的是共享的 redo log buffer 成組寫入）。假如有三個 事務，t1 , t2 , t3 ，同時提交，假設 t1 先進入到 刷硬盤的時機，他發現 buffer 中還有 t2 和 t3 的日志，會同時幫忙刷入到硬盤中（假如控制的參數是1的話）。稱為組提交。其實 t2，t3 就算不提交，也會被 t1 順帶落盤，很奇怪？為什么沒提交的事務的 redo log 也能落盤？其實還有 undo log ， 從數據頁可以找到 一條與之相關的 undo log 鏈。
記錄了 數據頁做出的變化。而 undo log 上記錄了 事務的 id，可以找到對應事務。當崩潰恢復，機器重啟時，雖然應用了硬盤中的未提交事務的 redolog，但是可以從 redolog 或者 其他地方找到 未提交的 事務，然后找到 對應的 undo log，進行回滾。
另外還有 binlog 的組提（binlog 的組提交是 多個線程 寫入 binlog 的 os cache，某個線程 sync 把其他 線程寫入 os cache 的內容 成組刷盤）。可以通過
binlog_group_commit_sync_delay 和 binlog_group_commit_sync_no_delay_count 兩個參數 控制 binlog 刷盤的延后，使更多事務同時 fsync
前者代表一個 binlog 提交延遲多久后 才 fsync，后一個代表一個 binlog 提交之后經過再多少個 binlog 提交才 fsync
（后者和 sync_binlog 不矛盾， t1, t2, t3 依次提交，假如 sync_binlog = 1 , binlog_group_commit_sync_no_delay_count = 2，那么 t1 暫時不 fsync，t2，t3 提交之后再 fsync， t2，t3 已經刷了盤
已經不能再做為起點計數了，如果再來各 t4，則從t4 開始算起）
實際的提交流程流程 ： redolog prepare 階段寫入 os cache - binlog 寫入os cache - redolog 的 fsync 刷盤階段（innodb_flush_log_at_trx_commit 控制是否刷盤）- binlog 的fsync 刷盤 - redolog 的commit 寫入 buffer。