GTID模式下跳过复制错误须先确认gtid_mode=ON，再停从库、禁用并行复制，严格执行SET GTID_NEXT→BEGIN;COMMIT;→重置AUTOMATIC，并用GTID_SUBTRACT验证是否生效，否则主从数据永久不一致。
确认当前是GTID模式且报错事务可丢弃
跳过前必须执行 SHOW VARIABLES LIKE 'gtid_mode';，返回 ON 才能继续；若为 OFF，SET GTID_NEXT 会直接报错 ERROR 1858。更重要的是：跳过不是修复，而是承认该事务“不该在从库执行”——比如主库已回滚、业务侧确认该操作无效、或从库已有相同数据导致冲突（如 1062 或 1146）。盲目跳过会导致主从数据永久不一致，尤其影响后续备份、切换和审计。
STOP SLAVE 后必须设 slave_parallel_workers = 0
多线程复制下 SET GTID_NEXT 行为不可控：你在一个会话设的值可能被其他 worker 线程忽略，空事务无法打上目标 GTID，后续 START SLAVE 会卡在 Waiting for master to send event 或触发 ERROR 1840。
- 先执行
STOP SLAVE; - 再执行
SET GLOBAL slave_parallel_workers = 0;，然后立刻SELECT @@slave_parallel_workers;确认返回0 - 这步不能省，MySQL 5.7.22+ 和 8.0 多数版本都存在该并发风险
严格三步执行：SET GTID_NEXT → BEGIN; COMMIT; → SET GTID_NEXT = 'AUTOMATIC'
GTID_NEXT 是会话级一次性指令，只预约下一个事务的 GTID，本身不产生事务。漏掉 COMMIT 或顺序错乱，MySQL 就永远等不到那个 GTID 落地，复制状态机不会推进。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 从
SHOW SLAVE STATUS\G的Last_SQL_Error中提取完整 GTID，例如e46c9961-5780-11ea-bf2f-000c128a8b6b:12345 - 执行：
SET SESSION GTID_NEXT = 'e46c9961-5780-11ea-bf2f-000c128a8b6b:12345'; - 立刻跟：
BEGIN; COMMIT;（不能用 DDL，部分 5.7 小版本对CREATE TABLE+ GTID 组合有 bug） - 最后重置：
SET SESSION GTID_NEXT = 'AUTOMATIC';（避免后续误操作污染会话）
验证是否真正跳过，别只盯 Executed_Gtid_Set
注入空事务后，SHOW SLAVE STATUS\G 中的 Executed_Gtid_Set 不会立刻变化——这是正常现象。MySQL 只在重放 relay log 时更新它，手工注入属于“外部写入”，不触发复制状态机自动推进。
真正有效的验证方式只有两个：
-
SELECT GTID_SUBTRACT('e46c9961-5780-11ea-bf2f-000c128a8b6b:12345', @@global.gtid_executed);返回空集合（即''），说明该 GTID 已被包含 -
START SLAVE;后，Seconds_Behind_Master开始下降，且不再重复报该 GTID 的错误
最容易被忽略的是：跳过之后不检查主从关键表行数、不验证 auto-increment 值偏移、也不测时间戳插入，就认为“同步恢复了”。其实数据覆盖风险往往藏在跳过之后的几轮变更里。
