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

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

sql_mode 也會被複製，但 NO_DIR_IN_CREATE 模式除外；無論來源上的變更為何，副本始終會保留自己的 NO_DIR_IN_CREATE 值。這適用於所有複製格式。

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

default_storage_engine 系統變數不會被複製，無論日誌模式為何；這旨在促進不同儲存引擎之間的複製。

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

系統變數 max_heap_table_size 不會被複製。如果在來源端增加此變數的值，而未在副本端進行相同操作，最終可能導致副本端在嘗試對來源端 MEMORY 表格執行 INSERT 陳述式時，產生 表格已滿 的錯誤。這是因為來源端的表格被允許成長到大於副本端對應表格的大小。更多資訊，請參閱第 19.5.1.21 節，「複製和 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 設定只能在初始化伺服器時進行配置。