當使用 STATEMENT 模式時，系統變數無法正確複製，但以下變數在搭配工作階段範圍使用時除外

當使用 MIXED 模式時，先前清單中的變數在搭配工作階段範圍使用時，會導致從基於陳述式的日誌記錄切換為基於列的日誌記錄。請參閱第 7.4.4.3 節，「混合二進位日誌格式」。

sql_mode 也會被複製，但 NO_DIR_IN_CREATE 模式除外；無論來源上的變更為何，副本永遠會保留其自己的 NO_DIR_IN_CREATE 值。所有複製格式皆是如此。

然而，當 mysqlbinlog 剖析 SET @@sql_mode = mode 陳述式時，包括 NO_DIR_IN_CREATE 在內的完整 mode 值會傳遞至接收伺服器。因此，當使用 STATEMENT 模式時，此類陳述式的複製可能不安全。

無論日誌模式為何，default_storage_engine 系統變數都不會被複製；這是為了方便不同儲存引擎之間的複製。

read_only 系統變數不會被複製。此外，在不同的 MySQL 版本中，啟用此變數對於暫存表格、表格鎖定和 SET PASSWORD 陳述式會有不同的影響。

max_heap_table_size 系統變數不會被複製。如果來源端此變數的值增加，但複本端沒有增加，則當在來源端嘗試對 MEMORY 表格執行 INSERT 陳述式時，可能會導致複本端最終出現 Table is full 錯誤，因為來源端的表格被允許成長到大於複本端的對應表格。更多資訊，請參閱第 19.5.1.22 節， “複製和 MEMORY 表格”。

在基於陳述式的複製中，當在更新表格的陳述式中使用時，連線變數無法正確複製。例如，以下陳述式序列不會在來源端和複本端插入相同的資料：

SET max_join_size=1000;
INSERT INTO mytable VALUES(@@max_join_size);

這不適用於常見的序列：

SET time_zone=...;
INSERT INTO mytable VALUES(CONVERT_TZ(..., ..., @@time_zone));

當使用基於列的複製時，連線變數的複製不會有問題，在這種情況下，連線變數始終可以安全地複製。請參閱第 19.2.1 節， “複製格式”。

以下連線變數會被寫入二進制日誌，並且在解析二進制日誌時，無論日誌格式為何，都會被複本端採用：

為了減少可能的混淆，我們建議您始終在來源端和複本端使用相同的 lower_case_table_names 系統變數設定，尤其是在具有區分大小寫檔案系統的平台上執行 MySQL 時。lower_case_table_names 設定只能在初始化伺服器時進行配置。