GTID复制为什么能自动找断点，而传统复制要手动指定 log_file
和 log_pos
因为GTID把“事务”本身变成了可追踪的实体，每个事务自带唯一身份证
server_uuid:transaction_id；从库通过
master_auto_position=1启动复制后，会自动比对本地已执行的
GTID_SET（存在
gtid_executed系统变量里）和主库提供的完整事务流，跳过所有已存在的GTID，只拉取缺失部分。传统复制没有这个元信息，只能靠人工记录并传递
mysql-bin.000001+
12345这样的位置坐标，一旦记错或日志被清理，就直接中断。 传统模式下，
CHANGE MASTER TO MASTER_LOG_FILE='...', MASTER_LOG_POS=...是必填项，且极易因备份时间差、日志轮转、误删导致偏移失效 GTID模式下，只要主从都开启
gtid_mode=ON且
enforce_gtid_consistency=ON，一句
CHANGE MASTER TO MASTER_HOST='...', MASTER_AUTO_POSITION=1;就够了 注意：
MASTER_AUTO_POSITION=1不是“智能猜测”，而是严格依赖双方
gtid_executed和
gtid_purged的集合运算，所以初始同步时必须确保从库的
GTID_PURGED设置准确（比如用
mysqldump --set-gtid-purged=ON导出）
为什么GTID从库必须开 log_bin
，而传统从库可以关
GTID要求每个从库也得“记住自己干过什么”，否则无法判断收到的GTID是否已执行过——这个记录就存在自己的
binlog里。传统复制只负责“重放”，不关心事务全局唯一性，所以从库默认不写
binlog，省IO也省空间。 GTID模式下，若从库未启用
log_bin，启动复制会报错：
ERROR 1792 (HY000): Changing the master configuration on a server running with GTID enabled is not allowed without enabling binary logging同时必须开启
log_slave_updates=1，确保从中继日志（
relay_log）回放的事务也会写进自己的
binlog，这样才能形成完整的GTID链路（尤其在级联复制中） 这意味着GTID从库的磁盘IO和存储开销天然高于传统从库，需提前评估容量与性能影响
GTID跳过错误事务为啥不能用 sql_slave_skip_counter
因为
sql_slave_skip_counter是按“事件条数”跳，而GTID是以“事务”为单位管理的，跳1条可能跳掉半个事务，破坏原子性。GTID强制事务粒度一致性，所以跳过必须基于GTID本身操作。 正确做法是注入空事务：
SET GTID_NEXT='xxx:yyy'; BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC';其中
xxx:yyy是出错的那个GTID，这样从库会认为“该事务已执行”，后续继续同步 更安全的方式是用
RESET SLAVE+
SET @@GLOBAL.GTID_PURGED = '...'清除已知冲突段，但前提是你要清楚哪些GTID不该再执行（常用于修复主从数据偏差） 传统复制中
sql_slave_skip_counter=1虽然危险，但至少语法上允许；GTID下该变量已被禁用，执行直接报错：
ERROR 1800 (HY000): sql_slave_skip_counter can not be set when the server is running with @@GLOBAL.GTID_MODE = ON
GTID真正省事的地方：故障切换时不用查一堆 SHOW MASTER STATUS
一主多从架构中，主库宕机后，选一个从库升主，其余从库要重新指向新主——传统方式得挨个登录原主（如果还能连）、查
SHOW MASTER STATUS，再登录每个从库改
CHANGE MASTER TO，稍有遗漏就会断复制。GTID让这事变成“配置即同步”。 新主执行
SELECT @@GLOBAL.GTID_EXECUTED;得到当前完整事务集，其他从库只需
CHANGE MASTER TO MASTER_HOST='new_master', MASTER_AUTO_POSITION=1;，自动对齐 但前提是整个集群必须统一开启GTID（
gtid_mode=ON），混合部署（部分节点GTID、部分非GTID）会导致复制彻底失败，MySQL明确禁止这种配置 另外，
gtid_mode在MySQL 5.6/5.7中不可动态修改，必须重启生效；MySQL 8.0.23+ 支持在线切换，但生产环境仍建议停机变更以避免状态不一致
GTID不是银弹，它用更强的一致性约束换来了配置简化，代价是更严格的兼容性要求和更少的手动干预空间。最容易被忽略的一点是：
enforce_gtid_consistency=ON不仅限制语句类型（比如禁用
CREATE TABLE ... SELECT），还会让某些合法SQL在GTID开启后直接报错——上线前务必在测试环境全量跑通业务SQL。
