最近，一直在糾結要不要改數據庫binlog的日志格式，原先用的是row格式，導致數據庫binlog日志較大，磁盤空間本來也不是很大，所以就想看看能不能改變binlog日志。在該binlog日志之前，先查詢一份關於binlog日志的講解,記錄如下：
一,mysql binlog共有三種日志 statement row mixed
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()函數
轉載：http://blog.itpub.net/15498/viewspace-2132115/