innodb_flush_log_at_trx_commit和sync_binlog是MySQL innodb引擎的兩個重要的引數，其中innodb_flush_log_at_trx_commit是將事務日誌從innodb log buffer寫入到redo log中，sync_binlog是將二進位制日誌檔案重新整理到磁碟上。

innodb事務日誌redo,binlog邏輯過程如下:
1.事務寫入redo log buffer中；
2.將log buffer重新整理到redo log中，不過會先寫一個TX PREPARE標記；
3.寫binlog
4.在redo log中寫入TX COMMIT標記；
5.將寫binlog成功的標記寫入redo log。

引數解析如下：
innodb_flush_log_at_trx_commit = N：

N=0 每隔一秒，把事務日誌快取區的資料寫到日誌檔案中，以及把日誌檔案的資料重新整理到磁碟上；
log buffer 會 每秒寫入到日誌檔案並刷寫（flush）到磁碟。但每次事務提交不會有任何影響，也就是 log buffer 的刷寫操作和事務提交操作沒有關係。在這種情況下，MySQL效能最好，但如果 mysqld 程序崩潰，通常會導致最後 1s 的日誌丟失。

N=1 每個事務提交時候，把事務日誌從快取區寫到日誌檔案中，並且重新整理日誌檔案的資料到磁碟上；
當取值為 1 時，每次事務提交時，log buffer 會被寫入到日誌檔案並刷寫到磁碟。這也是預設值。這是最安全的配置，但由於每次事務都需要進行磁碟I/O，所以也最慢。

N=2 每事務提交的時候，把事務日誌資料從快取區寫到日誌檔案中；每隔一秒，重新整理一次日誌檔案，但不一定重新整理到磁碟上，而是取決於作業系統的排程；
當取值為 2 時，每次事務提交會寫入日誌檔案，但並不會立即刷寫到磁碟，日誌檔案會每秒刷寫一次到磁碟。這時如果 mysqld 程序崩潰，由於日誌已經寫入到系統快取，所以並不會丟失資料；在作業系統崩潰的情況下，通常會導致最後 1s 的日誌丟失。
上面說到的「最後 1s」並不是絕對的，有的時候會丟失 更多資料。有時候由於排程的問題，每秒刷寫（once-per-second flushing）並不能保證 100% 執行。對於一些資料一致性和完整性要求不高的應用，配置為 2 就足夠了；如果為了最高效能，可以設定為 0。有些應用，如支付服務，對一致性和完整性要求很高，所以即使最慢，也最好設定為 1.
當我們設定為2 的時候，Log Thread 會在我們每次事務結束的時候將資料寫入事務日誌，但是這裡的寫入僅僅是呼叫了檔案系統的檔案寫入操作。而我們的檔案系統都是有快取機制的，所以Log Thread 的這個寫入並不能保證內容真的已經寫入到物理磁碟上面完成持久化的動作。檔案系統什麼時候會將快取中的這個資料同步到物理磁碟檔案Log Thread 就完全不知道了。所以，當設定為2 的時候，MySQL Crash 並不會造成資料的丟失，但是OS Crash 或者是主機斷電後可能丟失的資料量就完全控制在檔案系統上了。各種檔案系統對於自己快取的重新整理機制各不一樣，大家可以自行參閱相關的手冊。

sync_binlog = N：

N>0 每向二進位制日誌檔案寫入N條SQL或N個事務後，則把二進位制日誌檔案的資料重新整理到磁碟上；
N=0 不主動重新整理二進位制日誌檔案的資料到磁碟上，而是由作業系統決定；

推薦配置組合：

N=1,1 — 適合資料安全性要求非常高，而且磁碟IO寫能力足夠支援業務，比如充值消費系統；
N=1,0 — 適合資料安全性要求高，磁碟IO寫能力支援業務不富餘，允許備庫落後或無複製；
N=2,0或2,m(0<m<100) — 適合資料安全性有要求，允許丟失一點事務日誌，複製架構的延遲也能接受；
N=0,0 — 磁碟IO寫能力有限，無複製或允許複製延遲稍微長點能接受，例如：日誌性登記業務；
當兩個引數設定為雙1的時候，寫入效能最差，sync_binlog=N (N>1 ) innodb_flush_log_at_trx_commit=2 時，(在當前模式下)MySQL的寫操作才能達到最高效能。

資料安全性

當innodb_flush_log_at_trx_commit和sync_binlog 都為1時是最安全的，在mysqld 服務崩潰或者伺服器主機crash的情況下，binary log 只有可能丟失最多一個語句或者一個事務。但是魚與熊掌不可兼得，都為1會導致頻繁的IO操作，因此該模式也是最慢的一種方式。
當innodb_flush_log_at_trx_commit設定為0，mysqld程序的崩潰會導致上一秒鐘所有事務資料的丟失。
當innodb_flush_log_at_trx_commit設定為2，只有在作業系統崩潰或者系統掉電的情況下，上一秒鐘所有事務資料才可能丟失。

雙1適合資料安全性要求非常高，而且磁碟IO寫能力足夠支援業務，比如訂單,交易,充值,支付消費系統。雙1模式下，當磁碟IO無法滿足業務需求時，推薦的做法是innodb_flush_log_at_trx_commit=2 ，sync_binlog=N (N為500 或1000) 且使用帶蓄電池後備電源的快取cache，防止系統斷電異常。

閱讀原文