innodb_flush_log_at_trx_commit
提交事務的時候將 redo 日志寫入磁盤中，所謂的 redo 日志，就是記錄下來你對數據做了什么修改，比如對 “id=10 這行記錄修改了 name 字段的值為 xxx”，這就是一個日志。如果我們想要提交一個事務了，此時就會根據一定的策略把 redo 日志從 redo log buffer 里刷入到磁盤文件里去。此時這個策略是通過 innodb_flush_log_at_trx_commit 來配置的，他有幾個選項。
值為0 : 提交事務的時候，不立即把 redo log buffer 里的數據刷入磁盤文件的，而是依靠 InnoDB 的主線程每秒執行一次刷新到磁盤。此時可能你提交事務了，結果 mysql 宕機了，然后此時內存里的數據全部丟失。
值為1 : 提交事務的時候，就必須把 redo log 從內存刷入到磁盤文件里去，只要事務提交成功，那么 redo log 就必然在磁盤里了。注意，因為操作系統的“延遲寫”特性，此時的刷入只是寫到了操作系統的緩沖區中，因此執行同步操作才能保證一定持久化到了硬盤中。
值為2 : 提交事務的時候，把 redo 日志寫入磁盤文件對應的 os cache 緩存里去，而不是直接進入磁盤文件，可能 1 秒后才會把 os cache 里的數據寫入到磁盤文件里去。
可以看到，只有1才能真正地保證事務的持久性，但是由於刷新操作 fsync() 是阻塞的，直到完成后才返回，我們知道寫磁盤的速度是很慢的，因此 MySQL 的性能會明顯地下降。如果不在乎事務丟失，0和2能獲得更高的性能。
# 查詢
select @@innodb_flush_log_at_trx_commit;
sync_binlog
該參數控制着二進制日志寫入磁盤的過程。
該參數的有效值為0 、1、N：
0：默認值。事務提交后，將二進制日志從緩沖寫入磁盤，但是不進行刷新操作（fsync()），此時只是寫入了操作系統緩沖，若操作系統宕機則會丟失部分二進制日志。
1：事務提交后，將二進制文件寫入磁盤並立即執行刷新操作，相當於是同步寫入磁盤，不經過操作系統的緩存。
N：每寫N次操作系統緩沖就執行一次刷新操作。
將這個參數設為1以上的數值會提高數據庫的性能，但同時會伴隨數據丟失的風險。
二進制日志文件涉及到數據的恢復，以及想在主從之間獲得最大的一致性，那么應該將該參數設置為1，但同時也會造成一定的性能損耗。