基於語句的複製的優點

基於語句的複製的缺點

基於列的複製的優點

基於列的複製的缺點

經過驗證的技術。

寫入日誌檔的資料較少。當更新或刪除影響多個列時，這會導致日誌檔所需的儲存空間少得多。這也意味著可以更快地完成備份和從備份還原。

日誌檔包含所有進行變更的陳述式，因此可用於稽核資料庫。

對於 SBR 不安全的陳述式。  並非所有修改資料的陳述式（例如 INSERT DELETE、UPDATE 和 REPLACE 陳述式）都可以使用基於語句的複製進行複製。使用基於語句的複製時，任何非決定性行為都難以複製。此類資料修改語言 (DML) 陳述式的範例包括以下內容

無法使用基於陳述式的複寫正確複寫的陳述式會記錄類似於此處顯示的警告

[Warning] Statement is not safe to log in statement format.

在這種情況下，也會向用戶端發出類似的警告。用戶端可以使用 SHOW WARNINGS 顯示它。

INSERT ... SELECT 需要比使用基於列的複寫更多的列級鎖定。

需要表格掃描 (因為在 WHERE 子句中未使用索引) 的 UPDATE 陳述式必須鎖定比使用基於列的複寫更多的列。

對於 InnoDB：使用 AUTO_INCREMENT 的 INSERT 陳述式會封鎖其他非衝突的 INSERT 陳述式。

對於複雜的陳述式，必須在更新或插入列之前在複本上評估和執行該陳述式。使用基於列的複寫，複本只需要修改受影響的列，而無需執行完整的陳述式。

如果複本上的評估發生錯誤，尤其是在執行複雜的陳述式時，基於陳述式的複寫可能會隨著時間的推移，慢慢地增加受影響列的誤差幅度。請參閱第 19.5.1.30 節，「複寫期間的複本錯誤」。

預存函式使用與呼叫陳述式相同的 NOW() 值執行。但是，預存程序則不然。

決定性的可載入函式必須在複本上應用。

表格定義在來源和複本上必須（幾乎）相同。有關更多資訊，請參閱第 19.5.1.9 節，「在來源和複本上使用不同的表格定義進行複寫」。

從 MySQL 授權表格 (透過聯結清單或子查詢) 讀取資料但不修改它們的 DML 操作，會在 MySQL 授權表格上執行為非鎖定讀取，因此對於基於陳述式的複寫來說是不安全的。有關更多資訊，請參閱「授權表格並行」。

可以複寫所有變更。這是最安全的複寫形式。

在來源上需要較少的列鎖定，因此對於下列類型的陳述式可以實現更高的並行性

對於任何 INSERT、UPDATE 或 DELETE 陳述式，複本上需要的列鎖定更少。

RBR 可能會產生更多必須記錄的資料。若要複寫 DML 陳述式 (例如 UPDATE 或 DELETE 陳述式)，基於陳述式的複寫只會將陳述式寫入二進位日誌。相反，基於列的複寫會將每個變更的列寫入二進位日誌。如果陳述式變更許多列，基於列的複寫可能會將顯著更多的資料寫入二進位日誌；即使對於回滾的陳述式也是如此。這也意味著進行和還原備份可能需要更多時間。此外，二進位日誌會被鎖定更長的時間來寫入資料，這可能會導致並行問題。使用 binlog_row_image=minimal 來大幅減少缺點。

產生大型 BLOB 值的決定性可載入函式，使用基於列的複寫比使用基於陳述式的複寫需要更長的時間來複寫。這是因為會記錄 BLOB 資料行值，而不是產生資料的陳述式。

您無法在複本上看到從來源接收和執行的陳述式。但是，您可以使用帶有 --base64-output=DECODE-ROWS 和 --verbose 選項的 mysqlbinlog 查看變更的資料。

或者，使用 binlog_rows_query_log_events 變數，如果啟用，則在使用 -vv 選項時，會將包含陳述式的 Rows_query 事件新增至 mysqlbinlog 輸出。

對於使用 MyISAM 儲存引擎的表格，當將其作為基於列的事件套用至二進位日誌時，在複本上對 INSERT 陳述式需要比將它們作為陳述式套用時更強大的鎖定。這表示當使用基於列的複寫時，不支援在 MyISAM 表格上同時插入。