Retrieved_Gtid_Set出现空洞正常，仅表示IO线程已拉取但SQL线程尚未执行的GTID不连续，属安全中间态；Executed_Gtid_Set出现空洞才危险，意味着事务未执行导致数据丢失。
Retrieved_Gtid_Set 出现空洞是正常现象
Retrieved_Gtid_Set 记录的是从库 IO 线程已拉取但尚未执行的 GTID 集合，它本身不保证连续。空洞（比如 1-10:15-20 缺失 11-14）不表示数据丢失或复制异常，只是说明这些 GTID 对应的事务还在 relay log 里排队、没被 SQL 线程消费完。
常见导致 Retrieved_Gtid_Set 空洞的场景
空洞主要源于 IO 和 SQL 线程异步工作，以及并行回放机制：
- 并行复制启用时（
slave_parallel_workers > 0），SQL 线程按组提交、乱序应用事务，IO 线程却按主库顺序持续拉取，造成“已拉未执”的 GTID 区间天然不连续 - 大事务正在回放中，后续小事务已写入 relay log 并被 IO 线程计入
Retrieved_Gtid_Set，但因依赖关系或锁等待卡在 SQL 线程队列里 - 网络抖动或 relay log 刷盘延迟，导致部分 binlog event 已接收但尚未完整写入 relay log 文件，GTID 暂未被解析入库
和 Executed_Gtid_Set 空洞有本质区别
这是最容易混淆的关键点：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
Retrieved_Gtid_Set有空洞 → 安全，纯中间态，不影响一致性 -
Executed_Gtid_Set有空洞 → 危险，说明某些 GTID 对应的事务根本没执行（比如跳过错误后未补全、临时表中断、人工注入失败），意味着实际数据可能缺失 - 判断是否真出问题，永远以
Executed_Gtid_Set为准；Retrieved_Gtid_Set只反映“进度缓冲区”状态
不用干预，但要注意监控误判
很多监控脚本直接比对 Retrieved_Gtid_Set 和主库的 gtid_executed 来算“落后多少事务”，这种算法在并行复制下会严重高估延迟。真正有意义的指标是：
-
Seconds_Behind_Master（需结合网络状况交叉验证） - 从
SHOW SLAVE STATUS\G中提取Relay_Master_Log_File+Exec_Master_Log_Pos，与主库show master status的File+Position对齐比对 - 用
pt-heartbeat或自建时间戳表做端到端延迟测量
空洞本身不是故障信号，强行重置 reset slave all 反而会清空 relay log、触发全量重传，得不偿失。
