1 技術成熟 2 對於大量的更新刪除等操做，僅僅會寫入少許的變動結果，加速日誌獲取或者備份的速度 3 日誌文件包含了全部更改的語句，能夠用來作驗證數據庫
Disadvantages of statement-based replicationmysql
1.1 在UDF自定義函數中的語句 1.2 在DELETE和UPATE中沒有使用order by 進行限制的字句 1.3 如下函數不能在語句格式中進行復制 load_file() uuid() user() found_rows() 等,now()函數除外 1.4 相比行格式，insert ...select 須要更多的行級鎖 1.5 相比行格式,update語句須要鎖住大量的行來進行表掃描 1.6 對於InnoDB：使用AUTO_INCREMENT會阻塞其餘不衝突的INSERT語句(這裏大概是由於自增都是經過同一個鎖來控制的，因此會阻塞叼其餘insert語句) 1.7 在複雜的語句中，行被更新或者插入以前，在從服務器上會對語句進行評估和執行。若是是行復制，從服務器只須要更改受影響的行而不須要去處理全部的表 1.8 在從庫執行復雜語句中，因爲評估錯誤，隨着時間的超時，會對行的影響慢慢增多 1.9 存儲函數使用跟調用函數相同的now()時候，並非存儲過程真實的狀況 2.1 肯定性UDF必須應用在從屬上。 2.2 主和從的表的定義必需要一致
Advantages of row-based replicationsql
1 全部的更改均可以被複制，是一種安全的複製
2 對於主庫而言只有少許的行鎖，從而實現較高的併發性
2.1 insert ...select
2.2 帶有auto_increment的insert語句
2.3 對於update或delete語句，使用where字句不使用鍵或者不會更改大多數已經檢查的行
2.4 在從庫中任意使用insert ,update或delete語句只須要少許的行鎖
Disadvantages of row-based replication數據庫
1 RBR格式在日誌中會昌盛更多的數據記錄，複製DML語句，語句格式僅僅是記錄這條語句到二進制日誌，二航個事， 將每行的改變記錄進去，若是更改的行數越多，就會產生的數據寫入到二進制日誌則越多，這樣的話可使回滾 成爲現實。因爲記錄每行的變動，鎖住的時間將會更長，從而會引發併發的性能問題。可使用binlog_row_image=minimal 來減小這個併發問題 2 肯定性的UDF函數在基於航個事的複製狀況下會產生大量的BLOB值從而是複製的時間變成。 3 你不能在從庫上查看從主庫傳輸過來的的語句，可是你能夠經過mysqlbinlog帶上--base64-output=decode-rows 和--verbose參數來查看改變的數據 4 對於使用MyISAM存儲引擎的表，在將INSERT語句做爲基於行的事件應用於二進制日誌時，在將INSERT語句應用於語句時須要更強的鎖定。 這意味着在使用基於行的複製時不支持MyISAM表上的併發插入。
以上爲語句格式和行格式方面的優缺點，基於目前的複製和各個中間件的使用狀況看，全部的數據庫，都建議採用RBR的格式，而在5.7.7以後的版本，RBR也變成了默認的格式來支持生產的需求安全