臨時資料表的基於列的日誌記錄。 如第 19.5.1.31 節「複製與臨時資料表」中所述，使用基於列或混合格式時，臨時資料表不會被複製。如需更多資訊，請參閱第 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 選項為 CHANGE REPLICATION SOURCE TO 依據伺服器 ID 進行篩選。此選項適用於基於語句和基於列的日誌格式，但在 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 有助於防止問題發生，而且無論您使用哪種日誌格式或儲存引擎，都建議一律使用。