MySQL主从同步跳过事务必须用SET GTID_NEXT配合BEGIN;COMMIT;伪造空事务，不可省略或仅用START TRANSACTION；GTID值须严格匹配原事务；跳过会导致GTID集合出现空洞，影响切主和延迟监控，且sql_sla ve_skip_counter在GTID模式下被禁用。
MySQL主从同步跳过事务时，SET GTID_NEXT 必须配合 BEGIN; COMMIT;
直接执行 SET GTID_NEXT = 'xxx-xxx-xxx:123'; 然后什么都不做？这绝对是个坑。后续所有事务都会被拒绝写入，并报错 ERROR 1840 (HY000): @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.。原因在于，MySQL会认为你试图手动注入一个GTID，却没有提供与之匹配的事务体，导致状态不一致。
所以，正确的姿势是强制“伪造”一个空事务：
SET GTID_NEXT = 'e10c57b9-1234-11ef-8a5d-00155d012345:12345'; BEGIN; COMMIT; SET GTID_NEXT = 'AUTOMATIC';
- 这里的关键是必须使用
BEGIN; COMMIT;这对组合，仅用START TRANSACTION;或者干脆省略事务体都是无效的。 GTID_NEXT的值必须与原故障事务的完整GTID（包含UUID和事务号）严格一致，大小写、连字符一个都不能错。- 操作前务必确认从库处于
STOP SLA VE;状态，否则可能被并行复制线程干扰，导致操作失败或状态混乱。
用 gtid_purged 跳过一批事务，要先清空 gtid_executed
如果想跳过从 e10c57b9-1234-11ef-8a5d-00155d012345:1000 到 :2000 这一整段事务，直接修改 gtid_purged 是行不通的。MySQL的规则是，新设置的 gtid_purged 必须是当前 gtid_executed 集合的子集。而“跳过”本质上是在宣称“这些事务已经执行了”，但实际上并没有，这就产生了逻辑冲突。
唯一的可行路径是，先重置从库的GTID状态：
STOP SLA VE; RESET MASTER; SET GLOBAL gtid_purged = 'e10c57b9-1234-11ef-8a5d-00155d012345:1-999,e10c57b9-1234-11ef-8a5d-00155d012345:2001-999999';
RESET MASTER这一步至关重要，它会清空gtid_executed，为后续设置gtid_purged扫清障碍。- 拼接后的
gtid_purged字符串必须完整覆盖所有你打算“假装已执行”的GTID区间。哪怕只漏掉一个，从库在后续拉取binlog时依然会卡住。 - 需要警惕的是，这个操作相当于丢弃了当前从库所有的复制位点信息，仅适用于你百分百确认主库缺失的那部分事务不会影响业务数据的一致性。
跳过事务后，SHOW SLA VE STATUS\G 的 Retrieved_Gtid_Set 和 Executed_Gtid_Set 不再连续
跳过操作完成后，你会发现这两个集合中间出现了“空洞”。例如，Executed_Gtid_Set 显示为 e10c...:1-999,e10c...:2001-2005，而主库可能已经推进到了 :3000。这本身不是错误，但会带来两个非常实际的影响：
- 影响主从切换：如果在此期间需要进行主从切换，而新的主库binlog中并不包含那些被跳过的GTID，那么从库将无法自动与新的主库对齐，执行
CHANGE MASTER TO ... GTID_SET时会失败。 - 干扰延迟监控：很多监控脚本依赖
Executed_Gtid_Set中最大的事务号来估算复制延迟。一旦GTID序列出现空洞，这种计算方式的结果将严重失真。即便是Percona Toolkit的pt-heartbeat工具，在GTID模式下也无法感知跳过行为，其计算的延迟数值同样不可信。
不要用 sql_sla ve_skip_counter 配合 GTID
在GTID模式下，如果你尝试执行 SET GLOBAL sql_sla ve_skip_counter = 1;，会立刻收到报错：ERROR 1776 (HY000): Cannot use sql_sla ve_skip_counter when @@GLOBAL.GTID_MODE = ON.。这不是配置问题，而是MySQL的强制限制——GTID设计的核心就是通过全局唯一标识来追踪每一个事务，使用跳过计数器会直接破坏这条链的完整性。
如果在某些文档或老旧脚本里看到两者混用的说法，那基本可以断定，它要么根本没在GTID模式下运行过，要么作者根本没有进行过实际验证。
最后，一个真正麻烦的地方在于：跳过事务这个动作本身，并不会在日志中留下明确的痕迹。事后，DBA很难回溯“为什么这里的GTID序列断了一截”。因此，在线上执行跳过操作前，务必先用 mysqlbinlog 工具仔细解析对应的binlog文件，确认目标事务确实只包含普通的DML操作，且没有跨库的数据依赖。否则，等到跳过后才发现主从数据不一致，那就只能面临一个更棘手的局面：全量重建从库。
