MySQL常用配置引數說明

1、sync_binlog

sync_binlog=0，當事務提交之後，mysql不做fsync之類的磁碟同步指令重新整理binlog_cache中的資訊到磁碟，而讓filesystem自行決定什麼時候來做同步，或者cache滿了之後才同步到磁碟。

這個是效能最好的，但是風險也是最大的。因為一旦系統crash，在binlog_cache中的所有binlog資訊都會被丟失。

sync_binlog=1，當每進行1次事務提交之後，mysql將進行一次fsync之類的磁碟同步指令來將binlog_cache中的資料強制寫入磁碟。

sync_binlog=n，當每進行n次事務提交之後，mysql將進行一次fsync之類的磁碟同步指令來將binlog_cache中的資料強制寫入磁碟。

對高併發系統來說，sync_binlog設定為0和設定為1的系統寫入效能差距可能高達5倍甚至更多。

2、innodb_flush_log_at_trx_commit

innodb_flush_log_at_trx_commit=0，每隔一秒把log buffer刷到檔案系統中(os buffer)，並呼叫檔案系統的「flush」操作將快取重新整理到磁碟上去。

也就是說一秒之前的日誌都儲存在日誌緩衝區，如果機器宕掉，可能丟失1秒的事務資料。

innodb_flush_log_at_trx_commit=1，每次事務提交的時候，都把log buffer刷到檔案系統中(os buffer)，並呼叫檔案系統的「flush」操作將快取重新整理到磁碟上去。

資料庫對io的要求就非常高，如果底層的硬體提供的iops比較差，那麼mysql資料庫的併發很快就會由於硬體io的問題而無法提公升。

innodb_flush_log_at_trx_commit=2，每次事務提交的時候會把log buffer刷到檔案系統中(os buffer)，但並不會立即刷寫到磁碟

。如果只是mysql資料庫掛掉了，由於檔案系統沒有問題，那麼對應的事務資料並沒有丟失。如果資料庫所在的主機作業系統損壞或者突然掉電的情況下，資料庫的事務資料可能丟失1秒之類的事務資料。

好處，減少了事務資料丟失的概率，而對底層硬體的io要求也沒有那麼高(log buffer寫到檔案系統中，一般只是從log buffer的記憶體轉移的檔案系統的記憶體快取中，對底層io沒有壓力)。