innodb_flush_log_at_trx_commit 該參數控制重做日誌寫入磁碟的過程。我們知道 InnoDB 使用“Write Ahead Log”策略來避免數據丟失問題，即依靠重做日誌來保證數據能在丟失後進行恢復。因此，InnoDB 重做日誌的持久化非常重要。這個參數的預設值為1 首先需 ...
innodb_flush_log_at_trx_commit
該參數控制重做日誌寫入磁碟的過程。我們知道 InnoDB 使用“Write Ahead Log”策略來避免數據丟失問題，即依靠重做日誌來保證數據能在丟失後進行恢復。因此，InnoDB 重做日誌的持久化非常重要。這個參數的預設值為1
首先需要大致瞭解一下mysql日誌操作步驟：
log_buff --》 mysql寫 (write) --》 log_file --》 OS刷新 (flush) --》 disk
innodb_flush_log_at_trx_commit 參數解釋：
0（延遲寫）： log_buff -- 每隔1秒 --》 log_file — 實時 --》 disk
1（實時寫，實時刷）： log_buff — 實時 --》 log_file -- 實時 --》 disk
2（實時寫，延遲刷）： log_buff — 實時 --》 log_file -- 每隔1秒 --》 disk
該參數的有效值有 0、1、2：
0：事務提交時，不將重做日誌緩衝寫入磁碟，而是依靠 InnoDB 的主線程每秒執行一次刷新到磁碟。因此如果 MySQL 發生宕機，那麼就有可能丟失一部分事務。
1：事務提交時，會將重做日誌緩衝寫入磁碟，並且立即刷新（fsync()）。註意，因為操作系統的“延遲寫”特性，此時的刷入只是寫到了操作系統的緩衝區中，因此執行同步操作才能保證一定持久化到了硬碟中。
2：事務提交時，會將重做日誌緩衝寫入磁碟，但是不會立即進行刷新操作，因此只是寫到了操作系統的緩衝區。此時若操作系統發生宕機而沒有即使的同步，也可能會丟失一部分數據。
可以看到，只有1才能真正地保證事務的持久性，但是由於刷新操作 fsync() 是阻塞的，直到完成後才返回，我們知道寫磁碟的速度是很慢的，因此 MySQL 的性能會明顯地下降。如果不在乎事務丟失，，0和2能獲得更高的性能。
sync_binlog
該參數控制著二進位日誌寫入磁碟的過程。
該參數的有效值為0 、1、N：
0：預設值。事務提交後，將二進位日誌從緩衝寫入磁碟，但是不進行刷新操作（fsync()），此時只是寫入了操作系統緩衝，若操作系統宕機則會丟失部分二進位日誌。
1：事務提交後，將二進位文件寫入磁碟並立即執行刷新操作，相當於是同步寫入磁碟，不經過操作系統的緩存。
N：每寫N次操作系統緩衝就執行一次刷新操作。
將這個參數設為1以上的數值會提高資料庫的性能，但同時會伴隨數據丟失的風險。
二進位日誌文件涉及到數據的恢復，以及想在主從之間獲得最大的一致性，那麼應該將該參數設置為1，但同時也會造成一定的性能損耗。
