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 落地，复制状态机不会推进。

• 从 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 时更新它，手工注入属于“外部写入”，不触发复制状态机自动推进。

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载

真正有效的验证方式只有两个：

• SELECT GTID_SUBTRACT('e46c9961-5780-11ea-bf2f-000c128a8b6b:12345', @@global.gtid_executed); 返回空集合（即 ''），说明该 GTID 已被包含
• START SLAVE; 后，Seconds_Behind_Master 开始下降，且不再重复报该 GTID 的错误

最容易被忽略的是：跳过之后不检查主从关键表行数、不验证 auto-increment 值偏移、也不测时间戳插入，就认为“同步恢复了”。其实数据覆盖风险往往藏在跳过之后的几轮变更里。