mysql binlog_format row and Statement 比較

標籤：並發   pass   資料庫系統   format   管理   state   技術   replace   資訊   

兩種模式的對比：
Statement 優點
曆史悠久，技術成熟；
產生的 binlog 檔案較小；
binlog 中包含了所有資料庫修改資訊，可以據此來審核心數據庫的安全等情況；
binlog 可以用於即時的還原，而不僅僅用於複製；
主從版本可以不一樣，從伺服器版本可以比主伺服器版本高；

Statement 缺點：
不是所有的 UPDATE 語句都能被複製，尤其是包含不確定操作的時候；
調用具有不確定因素的 UDF 時複製也可能出現問題；
運用以下函數的語句也不能被複製：
* LOAD_FILE()
* UUID()
* USER()
* FOUND_ROWS()
* SYSDATE() (除非啟動時啟用了 –sysdate-is-now 選項)
INSERT … SELECT 會產生比 RBR 更多的行級鎖；
複製須要執行全表掃描 (WHERE 語句中沒有運用到索引) 的 UPDATE 時，須要比 row 請求更多的行級鎖；
對於有 AUTO_INCREMENT 欄位的 InnoDB 表而言，INSERT 語句會阻塞其他 INSERT 語句；
對於一些複雜的語句，在從伺服器上的耗資源情況會更嚴重，而 row 模式下，只會對那個發生變化的記錄產生影響；
儲存函數(不是儲存流程 )在被調用的同時也會執行一次 NOW() 函數，這個可以說是壞事也可能是好事；
確定了的 UDF 也須要在從伺服器上執行；
資料表必須幾乎和主伺服器保持一致才行，否則可能會導致複製出錯；
執行複雜語句如果出錯的話，會消耗更多資源；

Row 優點
任何情況都可以被複製，這對複製來說是最安全可靠的；
和其他大多數資料庫系統的複製技能一樣；
多數情況下，從伺服器上的表如果有主鍵的話，複製就會快了很多；
複製以下幾種語句時的行鎖更少：
* INSERT … SELECT
* 包含 AUTO_INCREMENT 欄位的 INSERT
* 沒有附帶條件或者並沒有修改很多記錄的 UPDATE 或 DELETE 語句
執行 INSERT，UPDATE，DELETE 語句時鎖更少；
從伺服器上採用多線程來執行複製成為可能；

Row 缺點
產生的 binlog 日誌體積大了很多；
複雜的復原時 binlog 中會包含大量的資料；
主伺服器上執行 UPDATE 語句時，所有發生變化的記錄都會寫到 binlog 中，而 statement 只會寫一次，這會導致頻繁發生 binlog 的寫並發請求；
UDF 產生的大 BLOB 值會導致複製變慢；
不能從 binlog 中看到都複製了寫什麼語句(加密過的)；
當在非事務表上執行一段堆積的 SQL 陳述式時，最好採用 statement 模式，否則很容易導致主從伺服器的資料不一致情況發生；
另外，針對系統庫 MySQL 裡面的表發生變化時的處理準則如下：
如果是採用 INSERT，UPDATE，DELETE 直接動作表的情況，則日誌格式根據 binlog_format 的設定而記錄；
如果是採用 GRANT，REVOKE，SET PASSWORD 等管理語句來做的話，那麼無論如何都要使用 statement 模式記錄；
使用 statement 模式後，能處理很多原先出現的主鍵重複問題

mysql binlog_format row and Statement 比較