GTID 复制能自动找断点是因为每个事务自带唯一 ID（server_uuid:transaction_id），从库通过比对 gtid_executed 与主库事务流自动跳过已执行事务；传统复制无此元信息，需手动指定 log_file 和 log_pos。
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。
