gtid模式不简化迁移动作本身，而是消除对位点的手动依赖和人工判断：传统切换需手动获取并核对file/position，易因延迟、binlog清理或跨库dml出错；gtid则通过比对@@global.gtid_executed集合实现确定性对齐，无模糊地带。
GTID模式本身不简化迁移流程，它只让“主从切换”这一步变得可自动化、可验证、可回退。真正简化的不是迁移动作，而是迁移中对位点的依赖和人工判断。
为什么传统迁移在切换时总卡在“最后一步”
旧架构下，停写旧主后必须手动执行 SHOW MASTER STATUS 获取 File 和 Position，再在新主上用 CHANGE MASTER TO MASTER_LOG_FILE='...', MASTER_LOG_POS=... 对齐——但这个位置是否真能覆盖所有未同步事务？没人敢 100% 确认。尤其当从库延迟波动、binlog被清理、或有跨库 DML 时，极易漏掉最后几条。
GTID 把这个问题从“找位置”变成“比集合”：SELECT @@global.gtid_executed 返回的是一个确定的 GTID 集合字符串，只要新主和原从库的该值一致，就代表所有事务已落地。没有模糊地带，也没有时钟/延迟干扰。
迁移前必须堵住的三个 GTID 兼容性漏洞
很多人一上来就 SET GLOBAL gtid_mode=ON，结果第二天业务报错一堆 GTID consistency violation。这不是 GTID 的问题，是你环境里还藏着不兼容操作：
-
CREATE TEMPORARY TABLE在事务中使用：MySQL 不允许临时表参与 GTID 事务，需拆出事务外执行 - MyISAM 表被
UPDATE或INSERT ... SELECT涉及：必须先转为ENGINE=InnoDB -
NOW()、UUID()、USER()等非确定函数出现在STATEMENT格式 binlog 中：必须确保binlog_format=ROW已全局生效
最稳妥的做法是先设 enforce_gtid_consistency=WARN，盯住错误日志 3 天，确认无警告再进下一步。
gtid_mode 切换不能跳步，四阶段缺一不可
MySQL 5.7+ 强制要求 gtid_mode 必须按顺序过渡：OFF → OFF_PERMISSIVE → ON_PERMISSIVE → ON。跳步会直接报错 ERROR 1789 (HY000)。
关键卡点在第三步到第四步之间：
- 执行
SET GLOBAL gtid_mode=ON_PERMISSIVE后，新事务开始生成 GTID，但老匿名事务仍存在 - 必须等所有节点都返回
ONGOING_ANONYMOUS_TRANSACTION_COUNT = 0，才能执行最终的SET GLOBAL gtid_mode=ON - 这个值不为 0，往往是因为某台从库 SQL_THREAD 还没追完旧 binlog，强行切会导致复制中断并报
Could not execute Write_rows event
从库切换复制源时，MASTER_AUTO_POSITION=1 不是银弹
CHANGE MASTER TO MASTER_AUTO_POSITION=1 只表示“启用 GTID 自动匹配”，但它能否成功，取决于三个隐性前提是否满足：
-
log_slave_updates=1必须开启：否则从库自己产生的 binlog 没有 GTID，级联复制断裂 -
binlog_format=ROW必须生效：STATEMENT格式在高延迟或跨机房场景下无法保证 GTID 安全传播 -
master_info_repository和relay_log_info_repository必须设为TABLE：否则 GTID 位置信息无法持久化，重启后丢失
最容易被忽略的是最后一项——很多线上实例仍用默认的 FILE 方式存 relay log 位置，切 GTID 后重启即失步。
GTID 真正的价值不在“开开关”，而在于把迁移中那些靠经验、靠运气、靠反复核对的环节，变成可查、可比、可脚本化的确定性操作。但前提是，你得先让数据库“说人话”，而不是让它在背后默默积累一堆匿名事务和不兼容语句。
