binlog二進位制日誌對於mysql資料庫的重要性有多大，在此就不多說了。下面根據本人的日常操作經歷，並結合網上參考資料，對binlog日誌使用做一梳理：
一、binlog日誌介紹
1. 什麼是binlog
binlog日誌用於記錄所有更新了資料或者已經潛在更新了資料（例如，沒有匹配任何行的一個DELETE）的所有語句。語句以“事件”的形式儲存，它描述資料更改。
2. binlog作用
因為有了資料更新的binlog，所以可以用於實時備份，與master/slave主從複製結合。
3. binlog有關引數
log_bin
設定此參數列示啟用binlog功能，並指定路徑名稱
log_bin_index
設定此引數是指定二進位制索引檔案的路徑與名稱
binlog_do_db
此參數列示只記錄指定資料庫的二進位制日誌
binlog_ignore_db
此參數列示不記錄指定的資料庫的二進位制日誌
max_binlog_cache_size
此參數列示binlog使用的記憶體最大的尺寸
binlog_cache_size
此參數列示binlog使用的記憶體大小，可以通過狀態變數binlog_cache_use和binlog_cache_disk_use來幫助測試。
binlog_cache_use：使用二進位制日誌快取的事務數量
binlog_cache_disk_use:使用二進位制日誌快取但超過binlog_cache_size值並使用臨時檔案來儲存事務中的語句的事務數量
max_binlog_size
Binlog最大值，最大和預設值是1GB，該設定並不能嚴格控制Binlog的大小，尤其是Binlog比較靠近最大值而又遇到一個比較大事務時，為了保證事務的完整性，不可能做切換日誌的動作，只能將該事務的所有SQL都記錄進當前日誌，直到事務結束
sync_binlog
這個引數直接影響mysql的效能和完整性
sync_binlog=0
當事務提交後，Mysql僅僅是將binlog_cache中的資料寫入Binlog檔案，但不執行fsync之類的磁碟 同步指令通知檔案系統將快取重新整理到磁碟，而讓Filesystem自行決定什麼時候來做同步，這個是效能最好的。
sync_binlog=n，在進行n次事務提交以後，Mysql將執行一次fsync之類的磁碟同步指令，同志檔案系統將Binlog檔案快取重新整理到磁碟。
Mysql中預設設定sync_binlog=0，即不作任何強制性的磁碟重新整理指令，這時效能是最好的，但風險也是最大的。一旦系統繃Crash，在檔案系統快取中的所有Binlog資訊都會丟失
這裡重點說下sync_binlog引數
MySQL提供一個sync_binlog引數來控制資料庫的binlog刷到磁碟上去。 sync_binlog選項控制mysql怎麼重新整理二進位制日誌到磁碟，預設是0，意味著mysql並不重新整理，由作業系統自己決定什麼時候重新整理快取到持久化設定，如果 這個值比0大，它指定了兩次重新整理到磁碟的動作之間間隔多少次二進位制日誌寫操作 如果沒有設定它為1，那麼崩潰後可能導致二進位制日誌沒有同步事務資料，這可以輕而易舉的導致複製中斷，並且使得及時恢復變得不可能，無論如何，可以 把這個值設定為1來獲得安全的保障，這樣就會要求mysql同步把二進位制日誌和事務日誌這兩個檔案重新整理到兩個不同的位置，這可能需要磁碟尋道，相對來說 是個很慢的操作。 ==================================================================================== 預設sync_binlog=0，表示MySQL不控制binlog的重新整理，由檔案系統自己控制它的快取的重新整理。這時候的效能是最好的，但是風險也是最大的。 因為一旦系統Crash，在binlog_cache中的所有binlog資訊都會被丟失。 如果sync_binlog>0，表示每sync_binlog次事務提交，MySQL呼叫檔案系統的重新整理操作將快取刷下去。最安全的就是sync_binlog=1了，表示 每次事務提交，MySQL都會把binlog刷下去，是最安全但是效能損耗最大的設定。這樣的話，在資料庫所在的主機作業系統損壞或者突然掉電的情 況下，系統才有可能丟失1個事務的資料。但是binlog雖然是順序IO，但是設定sync_binlog=1，多個事務同時提交，同樣很大的影響MySQL和IO 效能。雖然可以通過group commit的補丁緩解，但是重新整理的頻率過高對IO的影響也非常大。對於高併發事務的系統來說，"sync_binlog"設定為0和 設定為1的系統寫入效能差距可能高達5倍甚至更多。 所以很多MySQL DBA設定的sync_binlog並不是最安全的1，而是100或者是0。這樣犧牲一定的一致性，可以獲得更高的併發和效能。 ==================================================================================== binlog二進位制日誌檔案並不是每次寫的時候同步到磁碟。因此當資料庫所在作業系統發生當機時，可能會有最後一部分資料沒有寫入二進位制日誌檔案中， 這給恢復和複製帶來了問題。 引數sync_binlog=[N]表示每寫緩衝多次就同步到磁碟。如果將N設為1，即sync_binlog=1表示採用同步寫磁碟的方式來寫二進位制日誌，這時寫操作 不使用才做系統的緩衝來寫二進位制日誌。（備註：該值預設為0，採用作業系統機制進行緩衝資料同步）。 當sync_binlog=1，還會存在另外問題。當使用InnoDB儲存引擎時，在一個事務發出commit動作之前，由於sync_binlog設為1，因此會將二進位制日 志立即寫入磁碟。如果這時已經寫入了二進位制日誌，但是提交還沒有發生，並且此時發生了當機，那麼在Mysql資料庫下次啟動時，由於commit操作並 沒有發生，所以這個事務會被回滾掉。但是二進位制日誌已經記錄了該事務資訊，不能被回滾。 這個問題，可以將innodb_support_xa設為1來解決，確保二進位制日誌和InnoDB儲存引擎資料檔案的同步。從官方解釋來看，innodb_support_xa的 作用是分兩類： - 支援多例項分散式事務（外部xa事務），這個一般在分散式資料庫環境中用得較多。 - 支援內部xa事務，說白了也就是說支援binlog與innodb redo log之間資料一致性。
4. binlog的刪除
binlog的刪除可以手工刪除或自動刪除：
a）自動刪除binlog
通過binlog引數（expire_logs_days ）來實現mysql自動刪除binlog
mysql> show binary logs;
mysql> show variables like 'expire_logs_days'; //該參數列示binlog日誌自動刪除/過期的天數，預設值為0，表示不自動刪除
mysql> set global expire_logs_days=3; //表示日誌保留3天，3天后就自動過期。
b）手工刪除binlog
mysql> reset master; //刪除master的binlog，即手動刪除所有的binlog日誌
mysql> reset slave; //刪除slave的中繼日誌
mysql> purge master logs before '2012-03-30 17:20:00'; //刪除指定日期以前的日誌索引中binlog日誌檔案
mysql> purge master logs to 'binlog.000002'; //刪除指定日誌檔案的日誌索引中binlog日誌檔案
mysql> set sql_log_bin=1/0; //如果使用者有super許可權，可以啟用或禁用當前會話的binlog記錄
mysql> show master logs; //檢視master的binlog日誌列表
mysql> show binary logs; //檢視master的binlog日誌檔案大小
mysql> show master status; //用於提供master二進位制日誌檔案的狀態資訊
mysql> show slave hosts; //顯示當前註冊的slave的列表。不以--report-host=slave_name選項為開頭的slave不會顯示在本列表中
mysql> flush logs; //產生一個新的binlog日誌檔案
mysql binlog日誌自動清理及手動刪除案例說明：
當開啟MySQL資料庫主從時，會產生大量如mysql-bin.00000* log的檔案，這會大量耗費您的硬碟空間。
mysql-bin.000001
mysql-bin.000002
mysql-bin.000003
mysql-bin.000004
mysql-bin.000005
…
刪除這些binlog日誌有三種解決方法：
1.關閉mysql主從，關閉binlog；
例項操作如下：
[root@huqniupc ~]# vim /etc/my.cnf //註釋掉log-bin和binlog_format
# Replication Master Server (default)
# binary logging is required for replication
# log-bin=mysql-bin
# binary logging format - mixed recommended
# binlog_format=mixed
然後重啟資料庫
2.開啟mysql主從，設定expire_logs_days；
例項操作如下：
[root@huqniupc ~]# vim /etc/my.cnf //修改expire_logs_days,x是自動刪除的天數，一般將x設定為短點，如10
expire_logs_days = x //二進位制日誌自動刪除的天數。預設值為0,表示“沒有自動刪除”
此方法需要重啟mysql
當然也可以不重啟mysql,開啟mysql主從，直接在mysql裡設定expire_logs_days
> show binary logs;
> show variables like '%log%';
> set global expire_logs_days = 10;
3.手動清除binlog檔案，(比如Mysql> PURGE MASTER LOGS TO ‘MySQL-bin.010′;）
例項操作如下：
[root@huqniupc ~]# /usr/local/mysql/bin/mysql -u root -p
> PURGE MASTER LOGS BEFORE DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY); //刪除10天前的MySQL binlog日誌,附錄2有關於PURGE MASTER LOGS手動刪除用法及示例
> show master logs;
也可以重置master，刪除所有binlog檔案：
# /usr/local/mysql/bin/mysql -u root -p
> reset master; //附錄3有清除binlog時，對從mysql的影響說明
-----------------------------------------------------------------------------------------------------------------------------------------------
PURGE MASTER LOGS手動刪除用法及示例,MASTER和BINARY是同義詞
> PURGE {MASTER | BINARY} LOGS TO 'log_name'
> PURGE {MASTER | BINARY} LOGS BEFORE 'date'
刪除指定的日誌或日期之前的日誌索引中的所有二進位制日誌。這些日誌也會從記錄在日誌索引檔案中的清單中被刪除MySQL BIN-LOG 日誌，這樣被給定的日誌成為第一個。
例項：
> PURGE MASTER LOGS TO 'MySQL-bin.010'; //清除MySQL-bin.010日誌
> PURGE MASTER LOGS BEFORE '2008-06-22 13:00:00'; //清除2008-06-22 13:00:00前binlog日誌
> PURGE MASTER LOGS BEFORE DATE_SUB( NOW( ), INTERVAL 3 DAY); //清除3天前binlog日誌BEFORE，變數的date自變數可以為'YYYY-MM-DD hh:mm:ss'格式。
-----------------------------------------------------------------------------------------------------------------------------------------------
5. 清除binlog時，對從mysql的影響
如果有一個活躍的slave從屬伺服器，該伺服器當前正在讀取您正在試圖刪除的日誌之一，則本語句不會起作用，而是會失敗，並伴隨一個錯誤；不過如果slave從屬伺服器是關閉的（或master-slave主從關係關閉），並且碰巧清理了其想要讀取的日誌之一，則slave從屬伺服器啟動後不能複製；當從屬伺服器正在複製時，本語句可以安全執行，不需要停止它們。
6. binglog的檢視
通過mysqlbinlog命令可以檢視binlog的內容
[root@localhost ~]# mysqlbinlog /home/mysql/binlog/binlog.000003 | more
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#120330 16:51:46 server id 1 end_log_pos 98 Start: binlog v 4, server v 5.0.45-log created 120330 1
6:51:46
# Warning: this binlog was not closed properly. Most probably mysqld crashed writing it.
# at 196
#120330 17:54:15 server id 1 end_log_pos 294 Query thread_id=3 exec_time=2 error_code=0
SET TIMESTAMP=1333101255/*!*/;
insert into tt7 select * from tt7/*!*/;
# at 294
#120330 17:54:46 server id 1 end_log_pos 388 Query thread_id=3 exec_time=28 error_code=0
SET TIMESTAMP=1333101286/*!*/;
alter table tt7 engine=innodb/*!*/;
解析binlog格式：
位置
位於檔案中的位置，“at 196”說明“事件”的起點，是以第196位元組開始；“end_log_pos 294”說明以第294位元組結束
時間戳
事件發生的時間戳：“120330 17:54:46”
事件執行時間
事件執行花費的時間:"exec_time=28"
錯誤碼
錯誤碼為：“error_code=0”
伺服器的標識
伺服器的標識id：“server id 1”
注意下面幾點：
1) mysql的日誌切不可想象是可以恢復到任何時間的狀態，這個恢復是有前提的！
至少得有一個從日誌記錄開始後的資料庫備份，通過日誌恢復資料庫實際上只是一個對以前操作的回放過程而已，不用想得太複雜。
既然是回放操作，那麼就得注意了，如果是執行了兩次恢復那就相當於是回放了兩次，後果可想而知。
所以：
1）恢復前務必先備份資料.
2）由於二進位制檔案多,並且需要恢復的資料跨度大,可以考慮將日誌檔案合併在恢復.
2) 開啟binlog日誌功能
要想通過日誌恢復資料庫，必須首先在my.cnf檔案裡定義，log-bin=mysql-bin，這樣產生的binlog日誌名就是以mysql-bin命名的
3) 什麼時候會生成新的binlog檔案
1）在備份的時候加入--flush-logs
2）重新啟動mysql服務的時候
特別提示，mysql每次啟動都會重新生成一個類似mysql-bin.00000n的檔案，如果你的mysql每天都要重新啟動一次的話，這時候你就要特別注意不要選錯日誌檔案了。
二、binlog日誌格式介紹
1. Mysql binlog日誌有三種格式，分別是Statement、MiXED、ROW
1）Statement：每一條會修改資料的sql都會記錄在binlog中
優點：不需要記錄每一行的變化，減少了binlog日誌量，節約了IO，提高效能。(相比row能節約多少效能與日誌量，這個取決於應用的SQL情況，正常同一條記錄修改或者插入row格式所產生的日誌量還小於Statement產生的日誌量，但是考慮到如果帶條件的update操作，以及整表刪除，alter表等操作，ROW格式會產生大量日誌，因此在考慮是否使用ROW格式日誌時應該跟據應用的實際情況，其所產生的日誌量會增加多少，以及帶來的IO效能問題。)
缺點：由於記錄的只是執行語句，為了這些語句能在slave上正確執行，因此還必須記錄每條語句在執行的時候的一些相關資訊，以保證所有語句能在slave得到和在master端執行時候相同 的結果。另外mysql 的複製,像一些特定函式功能，slave可與master上要保持一致會有很多相關問題(如sleep()函式， last_insert_id()，以及user-defined functions(udf)會出現問題).
使用以下函式的語句也無法被複制：
* LOAD_FILE()
* UUID()
* USER()
* FOUND_ROWS()
* SYSDATE() (除非啟動時啟用了 --sysdate-is-now 選項)
同時在INSERT ...SELECT 會產生比 RBR 更多的行級鎖
2）Row:不記錄sql語句上下文相關資訊，僅儲存哪條記錄被修改
優點： binlog中可以不記錄執行的sql語句的上下文相關的資訊，僅需要記錄那一條記錄被修改成什麼了。所以rowlevel的日誌內容會非常清楚的記錄下每一行資料修改的細節。而且不會出現某些特定情況下的儲存過程，或function，以及trigger的呼叫和觸發無法被正確複製的問題
缺點:所有的執行的語句當記錄到日誌中的時候，都將以每行記錄的修改來記錄，這樣可能會產生大量的日誌內容,比如一條update語句，修改多條記錄，則binlog中每一條修改都會有記錄，這樣造成binlog日誌量會很大，特別是當執行alter table之類的語句的時候，由於表結構修改，每條記錄都發生改變，那麼該表每一條記錄都會記錄到日誌中。
3）Mixedlevel: 是以上兩種level的混合使用，一般的語句修改使用statment格式儲存binlog，如一些函式，statement無法完成主從複製的操作，則採用row格式儲存binlog,MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日誌形式，也就是在Statement和Row之間選擇一種.新版本的MySQL中隊row level模式也被做了優化，並不是所有的修改都會以row level來記錄，像遇到表結構變更的時候就會以statement模式來記錄。至於update或者delete等修改資料的語句，還是會記錄所有行的變更。
Mixed日誌說明：
在slave日誌同步過程中，對於使用now這樣的時間函式，MIXED日誌格式，會在日誌中產生對應的unix_timestamp()*1000的時間字串，slave在完成同步時，取用的是sqlEvent發生的時間來保證資料的準確性。另外對於一些功能性函式slave能完成相應的資料同步，而對於上面指定的一些類似於UDF函式，導致Slave無法知曉的情況，則會採用ROW格式儲存這些Binlog，以保證產生的Binlog可以供Slave完成資料同步。
2. binlog基本配製與格式設定
1）基本配製
binlog日誌格式可以通過mysql的my.cnf檔案的屬性binlog_format指定。如以下：
binlog_format = MIXED //binlog日誌格式
log_bin =目錄/mysql-bin.log //binlog日誌名
expire_logs_days = 7 //binlog過期清理時間
max_binlog_size 100m //binlog每個日誌檔案大小
binlog-do-db=需要備份的資料庫名，如果備份多個資料庫，重複設定這個選項即可
binlog-ignore-db=不需要備份的資料庫苦命，如果備份多個資料庫，重複設定這個選項即可
2）Binlog日誌格式選擇
Mysql預設是使用Statement日誌格式，推薦使用MIXED.
由於一些特殊使用，可以考慮使用ROWED，如自己通過binlog日誌來同步資料的修改，這樣會節省很多相關操作。對於binlog資料處理會變得非常輕鬆,相對mixed，解析也會很輕鬆(當然前提是增加的日誌量所帶來的IO開銷在容忍的範圍內即可)。
3）mysqlbinlog格式選擇
mysql對於日誌格式的選定原則:如果是採用 INSERT，UPDATE，DELETE 等直接操作表的情況，則日誌格式根據 binlog_format 的設定而記錄,如果是採用 GRANT，REVOKE，SET PASSWORD 等管理語句來做的話，那麼無論如何 都採用 SBR 模式記錄
3. Mysql Binlog日誌分析
通過MysqlBinlog指令檢視具體的mysql日誌，如下:
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
SET TIMESTAMP=1350355892/*!*/;
BEGIN
/*!*/;
# at 1643330
#121016 10:51:32 server id 1 end_log_pos 1643885 Query thread_id=272571 exec_time=0 error_code=0
SET TIMESTAMP=1350355892/*!*/;
Insert into T_test….)
/*!*/;
# at 1643885
#121016 10:51:32 server id 1 end_log_pos 1643912 Xid = 0
COMMIT/*!*/;
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
1.開始事物的時間:
SET TIMESTAMP=1350355892/*!*/;
BEGIN
2.sqlevent起點
#at 1643330 :為事件的起點，是以1643330位元組開始。
3.sqlevent 發生的時間點
#121016 10:51:32:是事件發生的時間，
4.serverId
server id 1 :為master 的serverId
5.sqlevent終點及花費時間，錯誤碼
end_log_pos 1643885:為事件的終點，是以1643885 位元組結束。
execTime 0: 花費的時間
error_code=0:錯誤碼
Xid:事件指示提交的XA事務
三、mysql日誌（重點binlog日誌）的優化說明
MySQL系統的伸縮性很強，既可以在充足的硬體資源環境下高效執行，也可以在極少資源環境下很好的執行，
但不管怎樣，儘可能充足的硬體資源對MySQL的效能提升總是有幫助的。
下面著重分析一下MySQL的日誌（主要是Binlog）對系統效能的影響，並根據日誌的相關特性得出相應的優化思路。
1. 日誌產生的效能影響
由於日誌的記錄帶來的直接效能損耗就是資料庫系統中最為昂貴的IO資源。
MySQL的日誌主要包括錯誤日誌（ErrorLog），更新日誌（UpdateLog），二進位制日誌（Binlog），查詢日誌（QueryLog），慢查詢日誌（SlowQueryLog）等。
特別注意：更新日誌是老版本的MySQL才有的，目前已經被二進位制日誌替代。
在預設情況下，系統僅僅開啟錯誤日誌，關閉了其他所有日誌，以達到儘可能減少IO損耗提高系統效能的目的。
但是在一般稍微重要一點的實際應用場景中，都至少需要開啟二進位制日誌，因為這是MySQL很多儲存引擎進行增量備份的基礎，也是MySQL實現複製的基本條件。
有時候為了進一步的mysql效能優化，定位執行較慢的SQL語句，很多系統也會開啟慢查詢日誌來記錄執行時間超過特定數值（由我們自行設定）的SQL語句。
一般情況下，在生產系統中很少有系統會開啟查詢日誌。因為查詢日誌開啟之後會將MySQL中執行的每一條Query都記錄到日誌中，會該系統帶來比較大的IO負擔，而帶來的實際效益卻並不是非常大。一般只有在開發測試環境中，為了定位某些功能具體使用了哪些SQL語句的時候，才會在短時間段內開啟該日誌來做相應的分析。
所以，在MySQL系統中，會對效能產生影響的MySQL日誌（不包括各儲存引擎自己的日誌）主要就是Binlog了。
2. Binlog 相關引數及優化策略
我們首先看看Binlog的相關引數，通過執行如下命令可以獲得關於Binlog的相關引數。
當然，其中也顯示出了“innodb_locks_unsafe_for_binlog”這個Innodb儲存引擎特有的與Binlog相關的引數：
mysql> show variables like '%binlog%'; +-----------------------------------------+----------------------+ | Variable_name | Value | +-----------------------------------------+----------------------+ | binlog_cache_size | 16777216 | | binlog_checksum | CRC32 | | binlog_direct_non_transactional_updates | OFF | | binlog_error_action | IGNORE_ERROR | | binlog_format | MIXED | | binlog_gtid_simple_recovery | OFF | | binlog_max_flush_queue_time | 0 | | binlog_order_commits | ON | | binlog_row_image | FULL | | binlog_rows_query_log_events | OFF | | binlog_stmt_cache_size | 32768 | | binlogging_impossible_mode | IGNORE_ERROR | | innodb_api_enable_binlog | OFF | | innodb_locks_unsafe_for_binlog | OFF | | max_binlog_cache_size | 18446744073709547520 | | max_binlog_size | 1073741824 | | max_binlog_stmt_cache_size | 18446744073709547520 | | simplified_binlog_gtid_recovery | OFF | | sync_binlog | 1 | +-----------------------------------------+----------------------+ 19 rows in set (0.00 sec)
“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倍甚至更多。
另：
MySQL的複製（Replication），實際上就是通過將Master端的Binlog通過利用IO執行緒通過網路複製到Slave端，然後再通過SQL執行緒解析Binlog中的日誌再應用到資料庫中來實現的。所以，Binlog量的大小對IO執行緒以及Msater和Slave端之間的網路都會產生直接的影響。
MySQL中Binlog的產生量是沒辦法改變的，只要我們的Query改變了資料庫中的資料，那麼就必須將該Query所對應的Event記錄到Binlog中。那我們是不是就沒有辦法優化複製了呢？當然不是，在MySQL複製環境中，實際上是是有8個引數可以讓我們控制需要複製或者需要忽略而不進行復制的DB或者Table的，分別為：
Binlog_Do_DB：設定哪些資料庫（Schema）需要記錄Binlog；
Binlog_Ignore_DB：設定哪些資料庫（Schema）不要記錄Binlog；
Replicate_Do_DB：設定需要複製的資料庫（Schema），多個DB用逗號（“,”）分隔；
Replicate_Ignore_DB：設定可以忽略的資料庫（Schema）；
Replicate_Do_Table：設定需要複製的Table；
Replicate_Ignore_Table：設定可以忽略的Table；
Replicate_Wild_Do_Table：功能同Replicate_Do_Table，但可以帶萬用字元來進行設定；
Replicate_Wild_Ignore_Table：功能同Replicate_Ignore_Table，可帶萬用字元設定；
通過上面這八個引數，我們就可以非常方便按照實際需求，控制從Master端到Slave端的Binlog量儘可能的少，從而減小Master端到Slave端的網路流量，減少IO執行緒的IO量，還能減少SQL執行緒的解析與應用SQL的數量，最終達到改善Slave上的資料延時問題。
實際上，上面這八個引數中的前面兩個是設定在Master端的，而後面六個引數則是設定在Slave端的。雖然前面兩個引數和後面六個引數在功能上並沒有非常直接的關係，但是對於優化MySQL的Replication來說都可以啟到相似的功能。當然也有一定的區別，其主要區別如下：
如果在Master端設定前面兩個引數，不僅僅會讓Master端的Binlog記錄所帶來的IO量減少，還會讓Master端的IO執行緒就可以減少Binlog的讀取量，傳遞給Slave端的IO執行緒的Binlog量自然就會較少。這樣做的好處是可以減少網路IO，減少Slave端IO執行緒的IO量，減少Slave端的SQL執行緒的工作量，從而最大幅度的優化複製效能。當然，在Master端設定也存在一定的弊端，因為MySQL的判斷是否需要複製某個Event不是根據產生該Event的Query所更改的資料
所在的DB，而是根據執行Query時刻所在的預設Schema，也就是我們登入時候指定的DB或者執行“USEDATABASE”中所指定的DB。只有當前預設DB和配置中所設定的DB完全吻合的時候IO執行緒才會將該Event讀取給Slave的IO執行緒。所以如果在系統中出現在預設DB和設定需要複製的DB不一樣的情況下改變了需要複製的DB中某個Table的資料的時候，該Event是不會被複制到Slave中去的，這樣就會造成Slave端的資料和Master的資料不一致的情況出現。同樣，如果在預設Schema下更改了不需要複製的Schema中的資料，則會被複制到Slave端，當Slave端並沒有該Schema的時候，則會造成複製出錯而停止。
而如果是在Slave端設定後面的六個引數，在效能優化方面可能比在Master端要稍微遜色一點，因為不管是需要還是不需要複製的Event都被會被IO執行緒讀取到Slave端，這樣不僅僅增加了網路IO量，也給Slave端的IO執行緒增加了RelayLog的寫入量。但是仍然可以減少Slave的SQL執行緒在Slave端的日誌應用量。雖然效能方面稍有遜色，但是在Slave端設定複製過濾機制，可以保證不會出現因為預設Schema的問題而造成Slave和Master資料不一致或者複製出錯的問題。
3. 慢查詢日誌Query Log 相關引數及使用建議
再來看看SlowQueryLog的相關引數配置。有些時候，我們為了定位系統中效率比較地下的Query語句，則需要開啟慢查詢日誌，也就是SlowQueryLog。我們可以如下檢視系統慢查詢日誌的相關設定：
mysql> show variables like 'log_slow%'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | log_slow_queries | ON | +------------------+-------+ 1 row in set (0.00 sec) mysql> show variables like 'long_query%'; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | long_query_time | 1 | +-----------------+-------+ 1 row in set (0.01 sec)
“log_slow_queries”引數顯示了系統是否已經開啟SlowQueryLog功能，而“long_query_time”引數則告訴我們當前系統設定的SlowQuery記錄執行時間超過多長的Query。在MySQLAB發行的MySQL版本中SlowQueryLog可以設定的最短慢查詢時間為1秒，這在有些時候可能沒辦法完全滿足我們的要求，如果希望能夠進一步縮短慢查詢的時間限制，可以使用Percona提供的microslow-patch（件成為mslPatch）來突破該限制。mslpatch不僅僅能將慢查詢時間減小到毫秒級別，同時還能通過一些特定的規則來過濾記錄的SQL，如僅記錄涉及到某個表的SlowQuery等等附加功能。
開啟SlowQueryLog功能對系統效能的整體影響沒有Binlog那麼大，畢竟SlowQueryLog的資料量比較小，帶來的IO損耗也就較小，但是，系統需要計算每一條Query的執行時間，所以消耗總是會有一些的，主要是CPU方面的消耗。如果大家的系統在CPU資源足夠豐富的時候，可以不必在乎這一點點損耗，畢竟他可能會給我們帶來更大效能優化的收穫。但如果我們的CPU資源也比較緊張的時候，也完全可以在大部分時候關閉該功能，而只需要間斷性的開啟SlowQueryLog功能來定位可能存在的慢查詢。
MySQL的其他日誌由於使用很少（QueryLog）或者效能影響很少，在此就不做過多分析了。