必须用set gtid_next+begin;commit;注入空事务，其他方式在gtid模式下均失败；准确获取卡住gtid需查last_sql_error中的完整gtid、retrieved_gtid_set与executed_gtid_set差集，并用replication_applier_status_by_worker验证；操作前须stop slave且slave_parallel_workers=0，否则gtid_next失效；begin;commit;为强制步骤，漏掉将致gtid状态永久错乱。
必须用 SET GTID_NEXT + BEGIN; COMMIT; 注入空事务，其他任何方式（包括 sql_slave_skip_counter）在 GTID 模式下都会失败或引发永久性错乱。
怎么准确拿到卡住的 GTID
不能靠猜，也不能只看 Last_SQL_Error 里模糊的描述。关键要看三处：
-
Last_SQL_Error字段中显式出现的完整 GTID，例如'6c9da32f-0513-11e4-a949-00e04c8a7573:1'—— 这是最直接线索 -
Retrieved_Gtid_Set和Executed_Gtid_Set的差集：前者是已拉取但未执行的 GTID 集合，后者是已执行的，差值就是待执行却卡住的部分 - 别查
performance_schema.replication_applier_status_by_coordinator—— 它不反映 worker 线程实际卡点；改用SELECT * FROM performance_schema.replication_applier_status_by_worker WHERE LAST_ERROR_NUMBER != 0;更准
为什么必须先停并行复制（slave_parallel_workers = 0）
因为 SET GTID_NEXT 是会话级设置，在多线程复制下不可控：你设的 GTID 可能被另一个 worker 拦截，导致空事务没打上目标 GTID，后续 START SLAVE 直接报 ERROR 1840 (HY000) 或卡死在 Waiting for master to send event。
- 执行顺序不能颠倒：先
STOP SLAVE，再SET GLOBAL slave_parallel_workers = 0，最后才设GTID_NEXT - 设完立刻验证：
SELECT @@slave_parallel_workers;必须返回0 - 有些 MySQL 版本在
slave_parallel_workers > 0时设了GTID_NEXT会静默失效，且不报错
BEGIN; COMMIT; 不是可选，是强制步骤
SET GTID_NEXT = 'xxx:nnn' 本身不产生事务，只是“预约”下一个事务的 GTID。你不手动提交一个事务，MySQL 就永远等不到那个 GTID 对应的事务落地，复制状态机不会推进。
- 漏掉
BEGIN; COMMIT;，或者COMMIT前连接断开，会导致从库 GTID 状态永久错乱 —— 此时重建从库是唯一选择 -
GTID_NEXT值必须严格匹配，大小写、冒号、分号都不能错；设完必须立刻重置为AUTOMATIC，否则后续事务可能被错误标记 - 执行完不要急着
START SLAVE，先确认Seconds_Behind_Master开始下降，且Retrieved_Gtid_Set与Executed_Gtid_Set差集缩小
最危险的不是操作步骤记错，而是跳过之后没查源头——比如 ERROR 1062 往往源于人为在从库误写入或主库用了非确定性语句，不修复这些，下一次冲突必然重现。
