enforce_gtid_consistency必须设为ON，否则gtid_mode=ON启动失败且无法回退；它强制拦截CREATE TABLE...SELECT、MyISAM写操作、非确定性函数等不安全语句，确保事务可重放与GTID唯一绑定。
必须设为 ON，否则 gtid_mode = ON 启动失败，且已开启 GTID 的实例无法回退到非 GTID 模式。
为什么 enforce_gtid_consistency 不能关
这个参数不是“建议开启”，而是 GTID 启用的硬性前提。MySQL 在 gtid_mode = ON 时会强制校验每条 SQL 是否满足 GTID 安全性要求——即事务必须可重放、无歧义、不依赖执行上下文。一旦检测到不兼容语句（比如 CREATE TABLE ... SELECT、更新 MyISAM 表、使用 UUID() 或用户变量等），就会直接报错拒绝执行。
常见错误现象包括：
- 从库
START SLAVE报错：ERROR 1786 (HY000): Statement violates GTID consistency - 主库执行某些 DDL 或混合事务时被拒绝，提示
GTID consistency violation - 配置文件里写了
gtid_mode = ON但 MySQL 启动失败，日志中明确提示需启用enforce_gtid_consistency
enforce_gtid_consistency = ON 的实际约束
它不只是开关，而是一套运行时拦截规则。开启后以下操作会被禁止：
-
CREATE TABLE ... SELECT（会拆成两个事务，GTID 无法唯一绑定） - 任何对
MyISAM表的写操作（不支持事务原子性） - 使用
LOAD DATA INFILE（除非配合SET SQL_LOG_BIN = 0，但该操作本身也受限制） - 在事务中调用
UUID()、USER()、@variable等非确定性函数 -
CREATE TEMPORARY TABLE+INSERT ... SELECT组合（同样破坏事务边界）
注意：enforce_gtid_consistency = ON 不影响只读查询，也不影响 innodb 表的常规 DML（INSERT/UPDATE/DELETE）和大部分 DDL（如 ADD COLUMN）。
配置顺序和重启要求
不能单独改这个参数：它必须和 gtid_mode 协同设置，且必须在 my.cnf 中静态配置，不支持动态修改（SET GLOBAL 无效）。
- 主从双方的
[mysqld]段都必须包含：gtid_mode = ONenforce_gtid_consistency = ONlog_bin = /path/to/binloglog_slave_updates = ONserver_id = xxx（唯一） - 修改后必须重启 MySQL 实例，否则配置不生效；重启失败说明有参数冲突或路径不可写
- 如果原实例已运行很久，且历史 binlog 中存在不兼容语句，
RESET MASTER无法绕过该检查——因为gtid_executed已包含这些事务，强行设gtid_purged会导致复制断裂
容易忽略的兼容性细节
即使参数全开，仍可能因隐含行为踩坑：
-
binlog_format必须是ROW，MIXED或STATEMENT下部分语句会触发一致性校验失败 - 从库若配置了
replicate-ignore-db，但主库跨库执行USE db1; INSERT INTO db2.t1 ...，会导致 GTID 执行位置错乱，enforce_gtid_consistency不拦，但复制会卡住 - 使用
mysqldump初始化从库时，必须加--set-gtid-purged=ON，否则导入后gtid_executed为空，CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1会找不到起点
真正麻烦的从来不是参数怎么写，而是你不知道哪些旧 SQL 已经悄悄埋了雷——上线前务必在测试库跑一遍全量业务 SQL，观察 error log 是否出现 GTID consistency violation。
