使用 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 系统变量不会被复制。在源上增加此变量的值，而在副本上不增加，最终会导致副本尝试在源上执行 INSERT 语句时出现 表已满 错误，而源上的 MEMORY 表因此被允许增长到大于副本上对应表的大小。有关更多信息，请参阅 第 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 设置只能在初始化服务器时配置。