在MySQL中，Executed_Gtid_Set 乱序增长通常指的是该集合中出现非连续的区间（即"空洞"）。这打破了正常情况下GTID应严格递增连续的预期，主要由以下四种场景导致：
- 并行复制
这是最常见的情况。从库开启并行复制后，多个worker线程并发回放事务。由于各事务提交速度不同，后面的可能先执行完，导致Executed_Gtid_Set在尾部出现暂时不连续。例如，1-92:94-96:98-100（缺失93、97等）。
· 特征：只要主库停止写入，从库追平后集合最终会恢复连续。
- 手动跳过事务
当复制因错误中断，管理员手动跳过一个事务时，该GTID会以单独区间被记录。若之前已执行到N，跳过N+1，集合会变成 1-N : N+2-M，形成永久空洞。
· 特征：属于永久性空洞，通常用于跳过确认为"安全"的错误。
- 直接修改GTID_PURGED
通过RESET MASTER后直接设置GTID_PURGED来"伪造"执行历史，会引入一个与当前实际执行状态不符的乱序集合。
· 风险：极易导致主从不一致或复制中断（如1236错误）。
- 主机崩溃
主库非正常关机，可能导致已发送到从库但尚未在本地落盘的事务丢失。从库记录的GTID集合因此多于重启后的主库，这种不一致在集合中表现为"多余的区间"。
· 特征：主库比从库"少"了某些GTID，是数据不一致的严重信号。
总结
Executed_Gtid_Set 中的乱序（空洞）并非一定是故障。并行复制导致的尾部临时空洞通常无需干预，而因手动跳过、参数误操作或主机崩溃导致的永久性不一致，则需要通过重建同步或数据校验来处理。
如果你在执行某个具体操作后发现了 GTID 乱序，可以告诉我具体场景，我帮你分析是否需要修复。