先给结论：用gtid_subtract(@@global.gtid_executed, '主库gtid_executed值')直接计算差集，返回非空即为从库缺失的gtid范围；必须以@@global.gtid_executed为准，而非show slave status中的executed_gtid_set（8.0.23+已移除且不实时）。
怎么看从库缺失哪些 GTID？用 GTID_SUBTRACT() 直接算差集
核心判断逻辑就是：主库已执行的 GTID 集合减去从库已执行的，剩下的就是从库没同步的。别手动比对、别翻日志，直接用 MySQL 内置函数算。
在从库上执行：SELECT GTID_SUBTRACT(@@global.gtid_executed, 'source_uuid:1-1000');
其中 'source_uuid:1-1000' 替换成你主库 SHOW MASTER STATUS 返回的 Executed_Gtid_Set 值（或从监控系统拿到的主库当前 GTID 集合）。
- 返回空字符串
''，说明该集合已全部执行，无缺失 - 返回类似
3E11FA47-71CA-11E1-9E33-C80AA9429562:1001-1005，就是具体缺失的事务范围 - 如果主库是多源复制或有多个 server_uuid，必须把完整 GTID 集合原样传入，不能只截一段
为什么 Executed_Gtid_Set 在 SHOW SLAVE STATUS 里看不到？得查 @@global.gtid_executed
SHOW SLAVE STATUS\G 中的 Executed_Gtid_Set 字段在 MySQL 8.0.23+ 已被移除，它不再实时更新，也不反映当前真实状态。现在唯一可信的是全局变量 @@global.gtid_executed。
- 执行
SELECT @@global.gtid_executed;才是当前从库真正执行过的所有 GTID - 这个值来自
mysql.gtid_executed表，重启后仍保留，比内存变量更可靠 - 注意：导入 dump 后若该值为空，说明
--set-gtid-purged=OFF没生效，或用了不兼容语句（如CREATE TABLE ... SELECT），导致事务未被识别为 GTID 事务
从库卡在某个 GTID 不动？先确认是 SQL 线程停了，不是网络或 IO 问题
常见误判：看到 Seconds_Behind_Master 是 0 就以为同步正常，其实 Slave_SQL_Running: No 时它恒为 NULL 或 0——这是最容易忽略的验证点。
- 必须先检查
Slave_SQL_Running和Last_SQL_Error，而不是看延迟时间 - 如果
Last_SQL_Error是Error_code: 1032或1062，说明数据层已不一致，跳过前得先评估业务影响 - 若
Retrieved_Gtid_Set和Executed_Gtid_Set完全相同，但Slave_SQL_Running是 No，大概率是事务本身执行失败（比如触发器报错、存储过程异常），不是位置问题
注入空事务修复时，GTID_NEXT 必须严格匹配错误日志里的缺失值
错误日志里通常会写明类似：The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.，接着会列出缺失的 GTID，例如 3E11FA47-71CA-11E1-9E33-C80AA9429562:1001。
- 注入前必须
STOP SLAVE;，且SET GTID_NEXT的值要和日志中一模一样，包括 UUID 大小写和数字 - 执行
BEGIN; COMMIT;后，@@global.gtid_executed会立刻增加这一项，但Executed_Gtid_Set在SHOW SLAVE STATUS里不会立即刷新——这是正常现象，别慌 - 注入后必须
SET GTID_NEXT='AUTOMATIC';，否则后续事务无法自动分配 GTID，复制会卡死
Retrieved_Gtid_Set 当成已执行集合来比对——它只是 IO 线程拉到的 GTID，不代表 SQL 线程已执行。真要定位“未同步”，只认 @@global.gtid_executed 和主库集合的差值。
