一、binlog是什麼
Binlog是Mysql sever層維護的一種二進制日誌，但是不能把binlog文件等同於innodb引擎中的redo/undo log。 主要是用來記錄對mysql數據更新或潛在發生更新的SQL語句，並以"事務"的形式保存在磁盤中
二、作用
主從複製：MySQL Replication在Master端開啓binlog，Master把它的二進制日誌傳遞給slaves並回放來達到master-slave數據一致的目的
數據恢復：通過mysqlbinlog工具恢復數據
增量備份
三、binlog格式
Mysql binlog日誌有ROW,Statement,MiXED三種格式；可通過my.cnf配置文件及 set global binlog_format=‘ROW/STATEMENT/MIXED’ 進行修改，命令行 show variables like ‘binlog_format’ 命令查看binglog格式；。
Row level: 僅保存記錄被修改細節，不記錄sql語句上下文相關信息優點：能非常清晰的記錄下每行數據的修改細節，不需要記錄上下文相關信息，因此不會發生某些特定情況下的procedure、function、及trigger的調用觸發無法被正確複製的問題，任何情況都可以被複制，且能加快從庫重放日誌的效率，保證從庫數據的一致性
缺點:由於所有的執行的語句在日誌中都將以每行記錄的修改細節來記錄，因此，可能會產生大量的日誌內容，干擾內容也較多；比如一條update語句，如修改多條記錄，則binlog中每一條修改都會有記錄，這樣造成binlog日誌量會很大，特別是當執行alter table之類的語句的時候，由於表結構修改，每條記錄都發生改變，那麼該表每一條記錄都會記錄到日誌中，實際等於重建了表。
tip: - row模式生成的sql編碼需要解碼，不能用常規的辦法去生成，需要加上相應的參數(–base64-output=decode-rows -v)才能顯示出sql語句; - 新版本binlog默認爲ROW level，且5.6新增了一個參數：binlog_row_image；把binlog_row_image設置爲minimal以後，binlog記錄的就只是影響的列，大大減少了日誌內容
Statement level: 每一條會修改數據的sql都會記錄在binlog中優點：只需要記錄執行語句的細節和上下文環境，避免了記錄每一行的變化，在一些修改記錄較多的情況下相比ROW level能大大減少binlog日誌量，節約IO，提高性能；還可以用於實時的還原；同時主從版本可以不一樣，從服務器版本可以比主服務器版本高
缺點：爲了保證sql語句能在slave上正確執行，必須記錄上下文信息，以保證所有語句能在slave得到和在master端執行時候相同的結果；另外，主從複製時，存在部分函數（如sleep）及存儲過程在slave上會出現與master結果不一致的情況，而相比Row level記錄每一行的變化細節，絕不會發生這種不一致的情況
Mixedlevel level: 以上兩種level的混合使用經過前面的對比，可以發現ROW level和statement level各有優勢，如能根據sql語句取捨可能會有更好地性能和效果；Mixed level便是以上兩種leve的結合。不過，新版本的MySQL對row level模式也被做了優化，並不是所有的修改都會以row level來記錄，像遇到表結構變更的時候就會以statement模式來記錄，如果sql語句確實就是update或者delete等修改數據的語句，那麼還是會記錄所有行的變更；因此，現在一般使用row level即可。
選取規則如果是採用 INSERT，UPDATE，DELETE 直接操作表的情況，則日誌格式根據 binlog_format 的設定而記錄
如果是採用 GRANT，REVOKE，SET PASSWORD 等管理語句來做的話，那麼無論如何都採用statement模式記錄