MySQL 8.0默认启用GTID是为了替代易出错的位点复制，通过事务唯一标识实现自动差集同步；启用需主从均设gtid_mode=ON、enforce_gtid_consistency=ON，并用MASTER_AUTO_POSITION=1代替文件位置参数。
MySQL 8.0 默认启用 GTID，不是为了“新潮”，而是位点复制在真实运维中容易卡死、配错、跳过错误后数据不一致——GTID 把“事务”本身变成可识别、可比对、可跳过的实体，让主从关系从“靠人记日志位置”升级为“靠系统算集合差”。
CHANGE MASTER TO 为什么能省掉 MASTER_LOG_FILE 和 MASTER_LOG_POS
因为 GTID 模式下，从库启动复制时不再依赖人工指定的文件名和偏移量，而是通过 MASTER_AUTO_POSITION=1 告诉 MySQL：“我只缺没执行过的事务”。MySQL 会自动比对 gtid_executed（本地已执行的 GTID 集合）和主库提供的事务流，拉取差集。
- 传统位点复制必须手动执行
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=12345，一旦备份时间与日志轮转不匹配，或日志被 purge，立刻报错Could not find first log file name in binary log index file - GTID 下只要主从都开启
gtid_mode=ON且enforce_gtid_consistency=ON，一句CHANGE MASTER TO MASTER_HOST='xxx', MASTER_AUTO_POSITION=1就够 - 注意：
MASTER_AUTO_POSITION=1不是“智能猜测”，它严格依赖双方gtid_executed和gtid_purged的集合运算，所以初始同步时必须用mysqldump --set-gtid-purged=ON导出，否则从库gtid_purged为空，主库无法判断该发哪些事务
故障切换时为什么不用再找位点、算偏移
传统一主两从架构中，如果主库宕机，需人工对比两个从库的 SHOW SLAVE STATUS\G 中的 Exec_Master_Log_Pos 和 Relay_Master_Log_File，再从 binlog 里逐条确认哪个从库更全；GTID 下只需看 SELECT GTID_SUBSET(gtid_executed, 'xxx:yyy') FROM performance_schema.global_variables 或直接比 SELECT @@global.gtid_executed 字符串长度，长的那个就是最新。
- 切换新主库后，其他从库只需执行
STOP SLAVE; CHANGE MASTER TO MASTER_HOST='new_master_ip', MASTER_AUTO_POSITION=1; START SLAVE;，自动追平 - 位点模式下，新主库可能已 purge 掉旧主库的 binlog，导致其他从库找不到起始位置，只能停服重搭
- GTID 的
server_uuid:transaction_id是全局唯一身份证，事务在哪台机器上提交过、执行过，系统自己记得清清楚楚
为什么 GTID 从库必须开 log_bin 和 log_slave_updates
因为 GTID 要求每个节点都能回答“这个事务我执行过了吗”，而判断依据就是它自己的 binlog 里有没有这条 GTID。如果从库不写 binlog，就无法维护 gtid_executed，复制链路在级联场景下会断裂。
- 不启用
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_executed就漏了这部分，下游从库无法正确比对 - 这意味着 GTID 从库磁盘 IO 和存储占用天然更高，尤其是大事务多、QPS 高的场景，得提前评估容量和刷盘压力
跳过错误事务为什么不能用 sql_slave_skip_counter
因为 sql_slave_skip_counter 是按 event 条数跳，而 GTID 是以完整事务为单位管理的。跳 1 条可能只跳过 BEGIN，留下 COMMIT 和后续语句，破坏原子性。
- GTID 下跳错必须显式注入空事务：
SET GTID_NEXT='xxx:yyy'; BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC'; - 其中
xxx:yyy是SHOW SLAVE STATUS\G中Retrieved_Gtid_Set和Executed_Gtid_Set的差集里的那个 GTID - 跳完要立刻执行
SELECT @@global.gtid_executed确认该 GTID 已出现在集合里，否则下次启动复制仍会重试
真正麻烦的不是配置 GTID，而是理解它把“事务身份”作为基础设施这件事——所有操作都围绕 GTID_SET 的交并补展开，而不是文件+偏移的线性坐标。一旦习惯这种思维，位点复制那种反复查日志、算位置、怕 purge 的焦虑感就消失了；但反过来，如果只是机械照搬参数却没校验 gtid_purged、忽略 log_slave_updates 的必要性，反而会让问题更隐蔽。
