直接查看从库当前执行过的GTID集合需执行SHOW SLAVE STATUS\G，关键字段为Executed_Gtid_Set，表示已成功回放的所有事务GTID集合，只读且仅在SQL线程完成事务后更新。
如何查看从库当前执行过的 GTID 集合
直接查 SHOW SLAVE STATUS\G，关键字段是 Executed_Gtid_Set。它表示该从库已成功执行（含 relay log 回放完成）的所有事务的 GTID 集合，是只读、不可修改的运行时状态。
注意：这个值不是实时刷新的——只有在 SQL 线程执行完一个事务并更新 relay log 位置后，才会同步更新 Executed_Gtid_Set。所以如果 SQL 线程卡住或刚启动还没开始回放，该字段可能为空或滞后。
- 若用的是 MySQL 5.7.6+，且启用了 GTID（
gtid_mode=ON），该字段才有效；否则显示为空 - 输出格式为多个 UUID:offset 区间，例如：
aaaabbbb-cccc-dddd-eeee-ffffffffffff:1-100 - 多源复制下，
Executed_Gtid_Set是所有通道合并后的并集，不是单个通道的
Executed_Gtid_Set 为空或不更新的常见原因
空值不等于“没数据”，更可能是状态未就绪或配置未生效。重点排查以下三点：
-
Slave_SQL_Running: No—— SQL 线程没运行，自然不会推进Executed_Gtid_Set；先看Seconds_Behind_Master和SQL_Delay -
gtid_mode=OFF或enforce_gtid_consistency=OFF—— 即使配置了master_auto_position=1，这两个参数也必须为ON才能生成 GTID 记录 - 主库写入的是非 GTID 事务（比如老版本主库、或显式禁用 GTID 的会话）—— 从库无法为其生成 GTID，也不会计入
Executed_Gtid_Set
验证方式：在从库执行 SELECT @@gtid_mode, @@enforce_gtid_consistency;，两个都必须返回 ON。
对比主从 GTID 集合差异判断同步延迟
主库的已执行 GTID 在 SELECT @@global.gtid_executed; 中，从库的在 SHOW SLAVE STATUS 的 Executed_Gtid_Set 字段里。二者差集就是从库缺失的事务。
MySQL 自带函数 GTID_SUBTRACT() 可直接算差：
SELECT GTID_SUBTRACT('aaaabbbb-cccc-dddd-eeee-ffffffffffff:1-100', 'aaaabbbb-cccc-dddd-eeee-ffffffffffff:1-90');
结果是 aaaabbbb-cccc-dddd-eeee-ffffffffffff:91-100，即从库还差这 10 个事务。
- 差集非空 ≠ 同步异常：可能是主库刚写入，从库还在追；需结合
Seconds_Behind_Master和Retrieved_Gtid_Set综合判断 -
Retrieved_Gtid_Set表示 IO 线程已拉到 relay log 但尚未执行的 GTID，它和Executed_Gtid_Set的并集才是当前从库“掌握”的全部 GTID - 跨版本或混合模式（GTID + binlog position）下，
GTID_SUBTRACT可能报错，此时应改用mysqlbinlog --base64-output=DECODE-ROWS -v手动比对
Executed_Gtid_Set 被清空或重置的典型场景
这个集合本身不能手动清空，但某些操作会导致它被重置为初始状态（如空集或仅含 bootstrap 事务），容易误判为“同步丢失”：
- 执行
RESET SLAVE ALL—— 不仅清空 relay log，还会重置Executed_Gtid_Set为''（空字符串） - 从库重建：用
mysqldump --set-gtid-purged=OFF导出再导入，新实例没有历史 GTID，Executed_Gtid_Set从零开始 - 主库执行
RESET MASTER后又没及时在从库执行CHANGE MASTER TO ... GTID_SET—— 从库继续拉日志时因 GTID 冲突报错，SQL 线程停止，Executed_Gtid_Set停滞
真正危险的是 Executed_Gtid_Set 比 Retrieved_Gtid_Set 还大——这说明 SQL 线程执行了不该执行的事务，大概率是人工干预（如跳过错误）导致 GTID 序列错乱，后续无法安全切换主库。
