跳过GTID复制错误必须先准确获取卡住的GTID：查SHOW SLA VE STATUS\G中的Last_SQL_Error、Retrieved_Gtid_Set与Executed_Gtid_Set差集，并确保STOP SLA VE后设sla ve_parallel_workers=0，再执行SET GTID_NEXT='xxx:nnn'; BEGIN; COMMIT;，最后验证Seconds_Behind_Master=0且GTID差集缩小。
确认报错事务的GTID值
跳过操作的第一步，也是最关键的一步，就是精准定位那个卡住复制的GTID。这事儿可不能靠猜，必须从数据库的状态里拿到确凿证据。直接运行 SHOW SLA VE STATUS\G，重点关注三个地方：Last_SQL_Error 字段里通常会包含完整的GTID信息；对比 Retrieved_Gtid_Set 和 Executed_Gtid_Set 的差集，也能反推出缺失的那个事务；如果SQL线程已经停止，Sla ve_SQL_Running_State 显示为类似 Waiting for dependent transaction to commit 的状态，那卡点就更加明确了。
这里有个常见的误区：别去 performance_schema.replication_applier_status_by_coordinator 表里找答案。这个视图只反映协调线程的视角，而GTID卡顿往往发生在工作线程层面，容易导致误判。真想进行交叉验证，更可靠的方法是查询 SELECT * FROM performance_schema.replication_applier_status_by_worker WHERE LAST_ERROR_NUMBER != 0;。
STOP SLA VE 后必须关掉并行复制
执行 STOP SLA VE 之后，有一个操作绝对不能忘：把 sla ve_parallel_workers 设置为0。为什么？因为如果并行复制还在运行，你后续执行的 SET GTID_NEXT 行为将变得不可预测。在多线程环境下，你设置的GTID可能会被其他工作线程拦截或忽略，导致空事务没能成功打上目标GTID。结果就是，当你信心满满地执行 START SLA VE 时，可能会直接收到 ERROR 1840 (HY000)，或者复制线程卡死在 Waiting for master to send event 的状态。
操作顺序至关重要，一步都不能乱：
- 首先，执行
STOP SLA VE; - 接着，立刻设置
SET GLOBAL sla ve_parallel_workers = 0;（改完后，务必用SELECT @@sla ve_parallel_workers;确认一下） - 最后，才轮到执行
SET GTID_NEXT = 'xxx:nnn';
改完设置先别急着重启复制。要知道，在某些MySQL版本中，如果 sla ve_parallel_workers 大于0时设置了 GTID_NEXT，这个设置可能会静默失效，而且不会抛出任何错误，让你误以为一切正常。
BEGIN; COMMIT; 不是可选，是强制步骤
很多人以为 SET GTID_NEXT = 'xxx:nnn' 就完事了，其实不然。这条命令本身并不产生事务，它只是“预约”了下一个事务的GTID编号。如果你不手动提交一个事务，MySQL就永远等不到这个GTID对应的“事务”落地，复制状态机也就无法向前推进。
实践中，经常能看到一些错误的写法：
SET GTID_NEXT = 'xxx:nnn'; COMMIT;—— 这是错的。没有BEGIN，COMMIT是无效的。尤其在从库设置了read_only=ON的情况下，MySQL会直接报错ERROR 1632 (HY000): Cannot execute statement in a READ ONLY transaction。- 通过执行
CREATE TABLE t1(id INT); DROP TABLE t1;这类DDL来产生事务 —— 不推荐。因为在部分MySQL版本（例如Percona 5.7.14）中，DDL操作对GTID的处理存在一些边界问题，可能会意外触发mysql.gtid_executed表的重建异常。
那么，正确且最简洁的写法是什么？就是老老实实地执行：BEGIN; COMMIT;。执行完毕后，立刻用 SELECT @@GTID_NEXT; 检查一下，确认它的值还是你设置的那个GTID，而不是已经自动变回了 AUTOMATIC。这一步能有效避免你误连到了其他会话而不自知。
注入后 Executed_Gtid_Set 不变？这是正常现象
成功注入空事务后，有些朋友会疑惑：为什么查看 SHOW SLA VE STATUS\G，里面的 Executed_Gtid_Set 字段看起来没有更新？这其实不代表操作失败了。因为这个字段只记录从Relay Log中“真正重放”的事务，而我们手工注入的事务属于“外部写入”，它不走标准的复制状态机流程。
要验证跳过操作是否真的成功了，应该看下面这三个地方：
Seconds_Behind_Master是否为0，且Sla ve_SQL_Running是否为Yes。Retrieved_Gtid_Set和Executed_Gtid_Set的差集是否缩小了（比如，原来差xxx:1，现在差xxx:2）。- 执行
SELECT GTID_SUBTRACT('xxx:1-5', 'xxx:1');，如果返回xxx:2-5，那就说明xxx:1已经被纳入已执行集合了，即使它没有显式地出现在Executed_Gtid_Set的字符串里。
最后，还有一个最容易被忽略的要点：跳过GTID之后，千万别立刻在从库上执行任何DML操作。因为你刚刚注入的GTID并没有对应真实的数据变更，如果紧接着就对同一张表进行写操作，很可能会掩盖底层的数据不一致。等到下次主库发来冲突的SQL语句时，问题才会暴露出来——到那时，处理起来可就麻烦多了。
