sync_binlog

“binlog_cache_size"：在事務過程中容納二進制日志SQL語句的緩存大小。二進制日志緩存是伺服器支援事務存儲引擎并且伺服器啟用了二進制日志(—log-bin選項)的前提下為每個用戶端配置設定的記憶體，注意，是每個Client都可以配置設定設定大小的binlogcache空間。如果讀者朋友的系統中經常會出現多語句事務的華，可以嘗試增加該值的大小，以獲得更有的性能。當然，我們可以通過MySQL的以下兩個狀态變量來判斷目前的binlog_cache_size的狀況：Binlog_cache_use和Binlog_cache_disk_use。

“max_binlog_cache_size”：和"binlog_cache_size"相對應，但是所代表的是binlog能夠使用的最大cache記憶體大小。當我們執行多語句事務的時候，max_binlog_cache_size如果不夠大的話，系統可能會報出“Multi-statementtransactionrequiredmorethan'max_binlog_cache_size'bytesofstorage”的錯誤。

“max_binlog_size”：Binlog日志最大值，一般來說設定為512M或者1G，但不能超過1G。該大小并不能非常嚴格控制Binlog大小，尤其是當到達Binlog比較靠近尾部而又遇到一個較大事務的時候，系統為了保證事務的完整性，不可能做切換日志的動作，隻能将該事務的所有SQL都記錄進入目前日志，直到該事務結束。這一點和Oracle的Redo日志有點不一樣，因為Oracle的Redo日志所記錄的是資料檔案的實體位置的變化，而且裡面同時記錄了Redo和Undo相關的資訊，是以同一個事務是否在一個日志中對Oracle來說并不關鍵。而MySQL在Binlog中所記錄的是資料庫邏輯變化資訊，MySQL稱之為Event，實際上就是帶來資料庫變化的DML之類的Query語句。

“sync_binlog”：這個參數是對于MySQL系統來說是至關重要的，他不僅影響到Binlog對MySQL所帶來的性能損耗，而且還影響到MySQL中資料的完整性。對于“sync_binlog”參數的各種設定的說明如下：

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

sync_binlog=n，當每進行n次事務送出之後，MySQL将進行一次fsync之類的磁盤同步指令來将binlog_cache中的資料強制寫入磁盤。

在MySQL中系統預設的設定是sync_binlog=0，也就是不做任何強制性的磁盤重新整理指令，這時候的性能是最好的，但是風險也是最大的。因為一旦系統Crash，在binlog_cache中的所有binlog資訊都會被丢失。而當設定為“1”的時候，是最安全但是性能損耗最大的設定。因為當設定為1的時候，即使系統Crash，也最多丢失binlog_cache中未完成的一個事務，對實際資料沒有任何實質性影響。從以往經驗和相關測試來看，對于高并發事務的系統來說，“sync_binlog”設定為0和設定為1的系統寫入性能差距可能高達5倍甚至更多。