Binary Log 記錄方式
Row Level
Binary Log會記錄成每一行數據被修改的形式，然后在Slave端再對相同的數據進行修改。
如果修改了表的結構，那么binlog日志記錄的是重新創建表，在插入字段、update等操作語句，而不是的alter的動作。
優點：在Row Level模式下，Binnary Log可以不記錄執行的Query語句的上下文相關信息，只要記錄哪一行修改了，修改成什么樣子。Row Level會詳細的記錄下每一行數據的修改細節，而且不會出現某個特定情況下的存儲過程，或Function，以及Trigger的調用和觸發無法被正確復制問題。
缺點：產生大量的日志內容。
Statment Level
每一條會修改的SQL語句都會記錄到Master的Binnary中。Slave端在復制的時候，SQL線程會解析成和原來Master端執行過相同的SQL語句，並再次執行。
優點：首先，解決了Row Level下的缺點，不須要記錄每一行的數據變化，減少了Binnary Log日志量，節約了IO成本，提高了性能。
缺點：由於它是記錄的執行語句，為了讓這些語句在Slave端也能正確執行。那么它還必須記錄每條語句在執行時的一些相關信息，即上下文信息，以保證所有語句在Slave端被執行的時候能夠得到和在Master端執行時相同的結果。另外，由於MySQL發展比較快，很多新功能不斷加入，使得MySQL復制遇到了不小的挑戰，復制時設計的內容岳父在，越容易出bug。在Statement Level下，目前已發現不少的情況下會造成MySQL的復制問題。主要是在修改數據使用了某些特定的函數貨功能后，出現，比如：Sleep()函數在有些版本中就不能正確的復制，在存儲過程中使用了last_insert_id()函數，可能會使Slave和Master的到不一致的ID，等等。
Mixed Level
在Mixed模式下，MySQL會根據執行的每一條具體的SQL語句來區分對待記錄的日志形式，也就是在Statement和Row之間選擇一種。除了MySQL認為通過Statement方式可能造成復制過程中Master和Slave之間產生不一致數據。(如特殊Procedure和Funtion的使用，UUID()函數的使用等特殊情況)時，它會選擇ROW的模式來記錄變更之外，都會使用Statement方式。