GTID模式下跳过ERROR 1062的唯一合规路径是伪造已执行GTID：先STOP SLAVE SQL_THREAD，提取Last_SQL_Error中的GTID，依次执行SET GTID_NEXT、BEGIN、COMMIT空事务，再SET GTID_NEXT='AUTOMATIC'并START SLAVE SQL_THREAD；跳过后须查根源、清脏数据、校验一致性。
直接跳过 ERROR 1062 是高风险操作，必须先确认是否启用 GTID —— 这是决定后续所有动作合法性的分水岭。盲目执行 SET GLOBAL sql_slave_skip_counter = 1 在 MySQL 8.0.23+ 默认环境下会立即报错 ERROR 1251，且可能导致复制永久中断。
怎么快速判断自己是不是 GTID 模式
这是所有修复动作的前提，不能靠猜测或配置文件推断：
- 执行
SHOW VARIABLES LIKE 'gtid_mode';，返回值为ON即已启用 GTID - 再执行
SHOW SLAVE STATUS\G，检查Executed_Gtid_Set和Retrieved_Gtid_Set是否非空、是否有差值 - 如果执行
SET GLOBAL sql_slave_skip_counter = 1报ERROR 1794或ERROR 1858，说明 GTID 已开但命令被拒绝，必须立刻停手
GTID 模式下跳过冲突事务的唯一合规路径
本质是“伪造一个已执行的 GTID”，让 SQL 线程跳过卡点，而非跳过下一条事件。漏一步、抄错一位、或 COMMIT 前连接断开，都会导致从库 GTID 状态永久错乱，只能重建从库：
- 先停 SQL 线程：
STOP SLAVE SQL_THREAD;（不是STOP SLAVE;，避免 IO 线程也停） - 从
SHOW SLAVE STATUS\G的Last_SQL_Error字段提取完整 GTID，例如：gtid:3e11fa47-71ca-11e1-9e33-c80aa9429562:23（注意冒号前后无空格、大小写严格一致） - 严格按顺序执行：
SET GTID_NEXT = '3e11fa47-71ca-11e1-9e33-c80aa9429562:23';→BEGIN;→COMMIT;（必须是空事务，不能带任何 DML） - 重置并恢复：
SET GTID_NEXT = 'AUTOMATIC';→START SLAVE SQL_THREAD;
跳过之后必须立刻做的三件事
跳过只是恢复同步的起点，不是终点。否则 1062 很可能在下一秒、另一张表再次爆发：
- 查根源：用
mysqlbinlog --base64-output=DECODE-ROWS -v解析对应 binlog，确认该INSERT是谁、何时、为何产生；同时在从库执行SELECT * FROM 表名 WHERE 主键 = X;，比对主库是否存在、是否多出一行 - 清脏数据：如果从库存在不该有的记录（如人为误插入），且业务允许，优先
DELETE FROM 表名 WHERE 主键 = X;，再启动复制——比跳过更安全、更可追溯 - 校一致性：跳过或清理后，必须用
pt-table-checksum或人工比对关键表主键范围，确认无隐性不一致；尤其要检查auto_increment_offset和auto_increment_increment是否主从匹配
真正容易被忽略的是：1062 不是孤立错误，它背后大概率存在从库绕过 read_only=ON 被写入、应用双写、或幂等缺失等问题。跳过操作本身没有副作用，但没查清源头的跳过，等于给复制链埋了一颗定时炸弹。
