GTID配置是否生效需三重验证：一查运行时变量值是否全为ON；二看SHOW SLAVE STATUS中Using_Gtid=Slave_Pos且Gtid_Set非空；三验事务同步去重行为是否正常，缺一不可。
GTID 配置是否生效，不能只看 my.cnf 里有没有写 gtid_mode=ON，必须查运行时值、确认复制状态、验证事务同步行为——三者缺一不可。
查 gtid_mode 和相关变量是否真开启
配置文件改完不等于生效，MySQL 启动时可能跳过错误行或加载了别的配置文件。直接连上 MySQL 执行：
SELECT @@global.gtid_mode, @@global.enforce_gtid_consistency, @@global.log_slave_updates;
期望输出全是 ON（注意大小写，OFF 或 OFF_PERMISSIVE 都不算生效）。如果返回 OFF，说明：
- 没重启 mysqld 服务（静态参数，必须重启）
- 配置写在了错误的段落，比如写在
[client]而不是[mysqld] - 被更高优先级配置覆盖（比如
~/.my.cnf里有冲突项） - MySQL 版本低于 5.6.5（极少见，但需确认：
SELECT VERSION();）
确认主从是否真正用 GTID 启动复制
即使 gtid_mode 开了，复制仍可能走传统 file/pos 模式。关键看 SHOW SLAVE STATUS\G 中这两项：
-
Using_Gtid: Slave_Pos（不是No，也不是空） -
Retrieved_Gtid_Set和Executed_Gtid_Set非空且格式为UUID:1-10类字符串
如果 Using_Gtid 是 No，说明 CHANGE MASTER TO 没带 MASTER_AUTO_POSITION = 1，或者执行前没清掉旧复制信息（RESET SLAVE ALL; 必须做）。
验证 GTID 同步行为是否正常
光看状态不卡住还不够，得验证事务真的按 GTID 规则传播和去重。实操建议：
- 主库建库建表插入一行：
CREATE DATABASE test_gtid; USE test_gtid; CREATE TABLE t1(id INT PRIMARY KEY); INSERT INTO t1 VALUES(1); - 立刻查从库：
SELECT * FROM test_gtid.t1;—— 应该能查到 - 再在主库执行相同 INSERT：
INSERT INTO t1 VALUES(2); - 从库执行
SHOW SLAVE STATUS\G，观察Executed_Gtid_Set是否新增了新事务 ID（如从uuid:1变成uuid:1-2） - 故意在从库手动插入
INSERT INTO t1 VALUES(2);（主键冲突），再在主库重试同一语句 —— 从库不应报错（GTID 自动跳过已执行事务）
如果第二次 INSERT 在从库报 Duplicate entry，说明 GTID 去重没起作用，大概率是 enforce_gtid_consistency 没开或主从 GTID 集合不同源（比如从库之前用传统方式同步过，没清空 gtid_executed）。
检查错误日志里有没有 GTID 相关警告
MySQL 不会因 GTID 配置错误直接启动失败，但会在错误日志里留痕迹。先查日志位置：
SELECT @@global.log_error;
然后 grep 关键词：
grep -i "gtid\|consistency" /var/log/mysql/error.log
重点关注这些内容：
-
[Warning] gtid_mode requires --log-bin→log_bin没开或路径无效 -
[Warning] enforce_gtid_consistency is OFF but gtid_mode is ON→ 参数没配全 -
[Warning] Skipping 'gtid_mode' as it was set to an invalid value→ 配置文件拼写错误（比如写成gtid-mode=ON，用了短横线）
最容易被忽略的是：GTID 生效依赖整个链路一致——主库、从库、复制账号权限、binlog_format=ROW 全部到位，漏一个环节，MASTER_AUTO_POSITION = 1 就会静默退回到传统模式。
