暫時資料表的基於列的記錄。 如第 19.5.1.32 節，「複製和暫時資料表」所述，使用基於列或混合格式時，不會複製暫時資料表。如需更多資訊，請參閱第 19.2.1.1 節，「基於陳述式和基於列的複製的優缺點」。

使用基於列或混合格式時，不會複製暫時資料表，因為沒有必要。此外，由於暫時資料表只能從建立它們的執行緒讀取，因此即使使用基於陳述式的格式，也很少有從複製它們中獲得任何好處。

即使已建立暫時資料表，您也可以在執行階段從基於陳述式切換為基於列的二進制記錄格式，但由於先前模式中已從二進制日誌中省略了任何 CREATE TEMPORARY TABLE 陳述式，因此您不能在執行階段從基於列或混合格式的二進制記錄切換為基於陳述式的格式。

MySQL 伺服器會追蹤每個暫時資料表建立時有效的記錄模式。當給定的用戶端工作階段結束時，伺服器會記錄每個仍然存在且在使用基於陳述式的二進制記錄時建立的暫時資料表的 DROP TEMPORARY TABLE IF EXISTS 陳述式。如果建立資料表時正在使用基於列或混合格式的二進制記錄，則不會記錄 DROP TEMPORARY TABLE IF EXISTS 陳述式。

只要受陳述式影響的任何非交易式資料表是暫時資料表，當使用 binlog_format=ROW 時，允許涉及暫時資料表的非交易式 DML 陳述式。

RBL 與非交易式表格的同步。 當許多列受到影響時，變更的集合會被分割成數個事件；當陳述式提交時，所有這些事件都會被寫入二進制日誌。在複本上執行時，所有涉及的表格都會被加上表格鎖定，然後以批次模式套用列。根據複本表格副本所使用的引擎，這可能有效也可能無效。

延遲與二進制日誌大小。 RBL 會將每一列的變更寫入二進制日誌，因此其大小可能會快速增加。這會顯著增加複本上與來源端變更相符所需的時間。您應該注意應用程式中可能發生的這種延遲。

讀取二進制日誌。 mysqlbinlog 使用 BINLOG 陳述式顯示二進制日誌中基於列的事件。此陳述式會將事件顯示為 base 64 編碼的字串，其含義並不明顯。當使用 --base64-output=DECODE-ROWS 和 --verbose 選項叫用時，mysqlbinlog 會將二進制日誌的內容格式化為人類可讀取的格式。當二進制日誌事件以基於列的格式寫入，並且您想要從複寫或資料庫故障中讀取或恢復時，您可以使用此命令來讀取二進制日誌的內容。如需更多資訊，請參閱 第 6.6.9.2 節「mysqlbinlog 列事件顯示」。

二進制日誌執行錯誤與複本執行模式。 使用 replica_exec_mode=IDEMPOTENT 通常僅適用於 MySQL NDB Cluster 複寫，其預設值為 IDEMPOTENT。（請參閱 第 25.7.10 節「NDB Cluster 複寫：雙向與環狀複寫」）。當 replica_exec_mode 為 IDEMPOTENT 時，由於找不到原始列而無法套用 RBL 的變更，不會觸發錯誤或導致複寫失敗。這表示更新可能未套用在複本上，因此來源和複本不再同步。當 replica_exec_mode 為 IDEMPOTENT 時，延遲問題和使用 RBR 的非交易式表格可能會導致來源和複本進一步分歧。如需有關 replica_exec_mode 的更多資訊，請參閱 第 7.1.8 節「伺服器系統變數」。

對於其他情況，將 replica_exec_mode 設定為 STRICT 通常就足夠了；這是 NDB 以外的儲存引擎的預設值。

不支援基於伺服器 ID 的篩選。 您可以使用 IGNORE_SERVER_IDS 選項來篩選基於伺服器 ID 的資料，此選項用於 CHANGE REPLICATION SOURCE TO。此選項適用於基於陳述式和基於列的日誌格式，但當 gtid_mode=ON 時無法使用。在某些複本上篩選出變更的另一種方法是使用 WHERE 子句，其中包含與 UPDATE 和 DELETE 陳述式的關係 @@server_id <> id_value 子句。例如，WHERE @@server_id <> 1。然而，這在基於列的日誌記錄中無法正常運作。若要將 server_id 系統變數用於陳述式篩選，請使用基於陳述式的日誌記錄。

RBL、非交易式表格與停止的複本。 當使用基於列的日誌記錄時，如果複本伺服器在複本執行緒更新非交易式表格時停止，則複本資料庫可能會達到不一致的狀態。因此，建議您對使用基於列格式複寫的所有表格使用交易式儲存引擎，例如 InnoDB。在關閉複本 MySQL 伺服器之前，使用 STOP REPLICA 或 STOP REPLICA SQL_THREAD 有助於防止問題發生，並且無論您使用哪種日誌記錄格式或儲存引擎，都建議這樣做。