最可靠的方法是比对@@global.gtid_executed：主从均STOP SLAVE后执行SELECT @@global.gtid_executed，结果完全相同即表示已执行事务集合一致；同时需确保Retrieved_Gtid_Set等于Executed_Gtid_Set，且server_uuid不同、gtid_purged为gtid_executed的子集。
直接比对 @@global.gtid_executed 是最可靠的方法
只要主从都处于 STOP SLAVE 状态，执行 SELECT @@global.gtid_executed;，结果完全相同就代表已执行事务集合一致——这是 GTID 模式下唯一可信赖的“最终一致性”判断依据。注意：不能在 START SLAVE 运行中查，SQL 线程可能正在追平，gtid_executed 是动态更新的，瞬时值无意义。
SHOW SLAVE STATUS\G 里的两个 GTID 集合必须相等
即使 Seconds_Behind_Master = 0，也不能说明数据已真正追平。关键要看：
-
Retrieved_Gtid_Set：从主库拉到 relay log 但尚未执行的 GTID 集合 -
Executed_Gtid_Set：已在本机执行完成的 GTID 集合
两者相等，才表示 relay log 已空、所有拉取的事务都已落地。若不等，说明还有积压，此时切主必然丢数据。
别信 mysql.gtid_executed 表的实时性
这个表只记录已刷盘到磁盘的 GTID，不是内存态快照。它不会包含当前正在写入 binlog 的事务，也不会立刻反映刚提交的事务（需等待 binlog flush）。所以：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
SELECT * FROM mysql.gtid_executed;只适合做归档分析或排查历史断点，不能用于实时一致性判断 - 它可能显示多个
source_uuid条目，若某 UUID 下 TID 序列中间有空洞（比如1-5,7-10），说明该实例曾丢失过事务，不可用于提升为主库 - 真正要验证一致性，永远优先用
@@global.gtid_executed变量值
最容易被忽略的隐性不一致：UUID 冲突与 gtid_purged 错配
主从 server_uuid 重复会导致从库拒绝接收同 UUID 的 GTID，错误如 Slave has more GTIDs than the master；而 gtid_purged 若被误清空或手动注入错误范围，会让从库跳过本该执行的事务。因此切主前必须检查：
-
SELECT @@global.server_uuid;—— 主从必须不同 -
SELECT @@global.gtid_purged;—— 从库的gtid_purged必须是主库gtid_executed的子集，否则复制无法建立 - 若从库执行过
RESET MASTER，必须重新初始化，不能直接切主
GTID 一致性不是“看起来一样”，而是“执行集合完全重合 + 元数据逻辑自洽”。少验一步，就可能在切换瞬间暴露数据断层。
