精准跳过GTID事务需三步：STOP SLAVE → SET GTID_NEXT='xxx:nnn' → BEGIN; COMMIT；必须确认该事务可丢弃，否则引发数据不一致，且不可用sql_slave_skip_counter。

跳过一个报错的GTID事务：先确认位置再注入空事务

MySQL复制中断在GTID模式下，常见错误是 Could not execute Write_rows event on table 或 Slave has retried X times，根本原因是主从间某个事务无法执行，但又不能跳过整个relay log——必须精准跳过那个GTID。

关键不是“怎么跳”，而是“跳之前必须确认它确实该跳”：比如该事务在从库已存在、或主库上早已被回滚、或业务侧确认可丢弃。盲目跳过会引发数据不一致。

• 先查报错时的GTID：SHOW SLAVE STATUS\G，看 Retrieved_Gtid_Set 和 Executed_Gtid_Set 的差集，再结合 Seconds_Behind_Master: NULL 和 SQL_Delay: 0 确认卡点
• 用 SELECT * FROM performance_schema.replication_applier_status_by_coordinator; 查当前正在重放哪个 GTID
• 别直接 SET GTID_NEXT —— 必须先 STOP SLAVE，且确保 slave_parallel_workers = 0（否则多线程下 GTID_NEXT 行为不可控）

SET gtid_next = 'xxx-yyy-zzz:123' 后必须立刻提交

SET GTID_NEXT 不是配置项，而是一次性会话级指令，它的作用只是“告诉MySQL：接下来这条语句，强制打上这个GTID”。它本身不产生事务，也不改变复制状态——你得手动补一条空事务让它落地。

漏掉 COMMIT 是最常踩的坑：设完 GTID_NEXT 就 START SLAVE，结果MySQL发现没有对应事务，直接报错 ERROR 1840 (HY000): @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty 或卡死在 Waiting for master to send event。

• 正确顺序只有三步：STOP SLAVE → SET GTID_NEXT = 'aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee:123'; → BEGIN; COMMIT;
• BEGIN; COMMIT; 是必须的，CREATE TABLE t1(id INT); DROP TABLE t1; 这类操作也行，但别用 DDL（某些版本对DDL的GTID处理有边界问题）
• 设完立刻 SELECT @@GTID_NEXT; 确认值没被自动重置（比如误连了其他会话）

注入空事务后，Executed_Gtid_Set 不会自动更新？

注入成功后，SHOW SLAVE STATUS\G 里的 Executed_Gtid_Set 看起来没变，这是正常现象。MySQL只在真正执行relay log里的事务时才更新它；你手工注入的事务属于“外部写入”，不会触发复制状态机的自动推进。

真正要看的是：SELECT GTID_SUBTRACT('aaa-bbb-ccc:1-123', @@global.gtid_executed); 返回空集合，说明该GTID已被包含；同时 START SLAVE 后不再报那个GTID的错，才代表跳过生效。

• 别依赖 Executed_Gtid_Set 字符串长度或末尾数字判断是否成功
• 如果跳过后仍报错，大概率是 GTID_NEXT 值写错了（比如少了一位、用了小写uuid、冒号前后空格）——GTID校验严格，错一位就完全不匹配
• 5.7.20+ 和 8.0.22+ 对 GTID_NEXT 的合法性检查更严，非法格式会直接拒绝设置，而不是静默失败

为什么不用 sql_slave_skip_counter？

因为开了GTID就不能用 sql_slave_skip_counter。MySQL会直接报错：ERROR 1794 (HY000): The slave is configured with MASTER_AUTO_POSITION = 1, but the master does not support GTID-based replication（即使主库支持，只要启用了 MASTER_AUTO_POSITION，这个变量就被禁用）。

本质是设计取舍：GTID要求“每个事务全球唯一可追溯”，跳过机制必须基于GTID本身，而非偏移量。想绕开只能临时关GTID（停主从、改配置、重启），但代价远高于注入空事务，且风险极高。

• 不要试图在GTID模式下 SET GLOBAL sql_slave_skip_counter = 1 —— 它会静默失效，或者触发不可预知的复制断裂
• 如果经常要跳事务，说明上游写入不规范（比如主库执行了非事务引擎表操作、或用了 CREATE TEMPORARY TABLE），该修的是源头，不是反复跳
• 8.0.23+ 支持 STOP REPLICA UNTIL SQL_BEFORE_GTIDS = '...'，但仍是辅助手段，不能替代精准注入

真正麻烦的从来不是那几条命令，而是确认“这个GTID到底能不能跳”——日志里没记录、业务没留痕、开发说“应该没问题”，这种时候注入空事务就是把不确定变成确定的错误。