1、statement level模式

每一條會修改數據的sql都會記錄到master的bin-log中。slave在復制的時候sql進程會解析成和原來master端執行過的相同的sql來再次執行。
優點：statement level下的優點，首先就是解決了row level下的缺點，不需要記錄每一行數據的變化，減少bin-log日誌量，節約io，提高性能。因為他只需要記錄在master上所執行的語句的細節，以及執行語句時候的上下文的信息。
缺點：由於它是記錄的執行語句，所以為了讓這些語句在slave端也能正確執行，那麽他還必須記錄每條語句在執行的時候的一些相關信息，也就是上下文信息，以保證所有語句在slave端被執行的時候能夠得到和在master端執行時候相同的結果。另外就是,由於mysql現在發展比較快，很多的新功能加入，使mysql的復制遇到了不小的挑戰,自然復制的時候涉及到越復雜的內容，bug也就越容易出現。在statement level下，目前已經發現的就有不少情況會造成mysql的復制問題，主要是修改數據的時候使用了某些特定的函數或者功能的時候會出現，比如sleep()在有些版本就不能正確復制。

2、rowlevel模式

日誌中會記錄成每一行數據被修改的形式，然後在slave端再對相同的數據進行修改
優點：bin-log中可以不記錄執行的sql語句的上下文相關的信息，僅僅只需要記錄那一條記錄被修改了，修改成什麽樣了。所以row level的日誌的內容會非常清楚的記錄下每一行數據修改的細節。而且不會出現某些特定情況下的存儲過程，或function,以及trigger的調用和觸發無法被正確復制的問題。
缺點：row level下，所有的執行的語句當記錄到日誌中的時候，都將以每行記錄的修改記錄，這樣可能會產生大量的日誌內容，比如有這樣一條update語句：update product set owner_member_id=‘d‘ where owner_member_id=‘a‘,執行之後，日誌中記錄的不是這條update語句所對應的事件(mysql是以事件的形式來記錄bin-log日誌)，而是這條語句所更新的每一條記錄的變化情況，這樣就記錄成很多條記錄被更新的很多事件。自然，bin-log日誌的量會很大。

3、mixed模式
實際上就是前兩種模式的結合，在mixed模式下，mysql會根據執行的每一條具體的sql語句來區分對待記錄的日誌形式，也就是在statement和row之間選一種。新版本中的statement level還是和以前一樣，僅僅記錄執行的語句。而新版本的mysql中對row level模式被做了優化，並不是所有的修改都會以row level來記錄，像遇到表結構變更的時候就會以statement模式來記錄，如果sql語句確實就是update或者delete 等修改數據的語句，那麽還是會記錄所有行的變更。

調整binlog日誌模式

mysql> show variables like ‘%binlog_format%‘;
+---------------+-----------+
| Variable_name | Value     |
+---------------+-----------+
| binlog_format | STATEMENT |
+---------------+-----------+
1 row in set (0.00 sec)

set global binlog_format = ‘?‘

原本是statement level，然後我改成了row level模式，然後切割一下binlog，接著對數據庫進行一些操作，然後去最新的bin-log日誌裏面用下列語句查看內容
mysqlbinlog --base64-output=decode-rows -v mysql-bin.000016

mysql binlog日誌的三種模式