MySQL的binlog的格式及優缺點介紹

MySQL binlog日誌有三種格式，分別為Statement,MiXED和ROW.

1.Statement：每一條會修改資料的sql都會記錄在binlog中。
優點:
binlog檔案較小
日誌是包含使用者執行的原始SQL,方便統計和審計
出現最早，相容較好
缺點：
存在安全隱患，可能導致主從不一致
對一些系統函式不能準確複製或是不能複製

2.ROW不記錄sql語句上下文相關資訊，僅儲存哪條記錄被修改。
優點:
相比statement更加安全的複製格式
在某些情況下複製速度更快（SQL複雜，表有主鍵）
系統的特殊函式也可以複製
更少的鎖
更新和刪除語句檢查是否有主鍵，如果有則直接執行，如果沒有，看是否有二級索引，如再沒有，則全表掃描
缺點：
binlog比較大（myql5.6支援binlog_row_image）
單語句更新（刪除）表的行數過多，會形成大量binlog
無法從binlog看見使用者執行SQL（5.6中增加binlog_row_query_log_events記錄使用者的query）

3.Mixed: 是以上兩種level的混合使用，一般的語句修改使用statment格式儲存binlog，如一些函式，statement無法完成主從複製的操作，則採用row格式儲存binlog,MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日誌形式，也就是在Statement和Row之間選擇一種.新版本的MySQL中隊row level模式也被做了最佳化，並不是所有的修改都會以row level來記錄，像遇到表結構變更的時候就會以statement模式來記錄。至於update或者delete等修改資料的語句，還是會記錄所有行的變更。
優點:
混合使用row和statement格式，對於DDL記錄statument,對於table裡的行操作記錄為row格式。
如果使用innodb表，事務級別使用了READ_COMMITTED or READ_UMCOMMITTED日誌級別只能使用row格式。
但是使用ROW格式中DDL語句還是會記錄成statement格式。
缺點:
mixed模式中，那麼在以下幾種情況下自動將binlog模式由SBR模式改成RBR模式。
當DML語句更新一個NDB表
當函式中包含UUID時
2個及以上auto_increment欄位的表被更新時
行任何insert delayed語句時
用UDF時
檢視中必須要求使用RBR時，例如建立檢視使用了UUID()函式