必须先执行show variables like 'gtid_mode'确认是否为on，gtid模式下sql_slave_skip_counter已弃用，须用stop replica→set gtid_next→begin;commit→set gtid_next='automatic'→start replica五步注入空事务跳过，漏一步或抄错gtid将导致复制永久中断。
ERROR 1062 不是“同步慢了”或“临时卡顿”，而是主从数据已实际不一致的明确信号。跳过错误本身极容易引发后续错位，必须先确认是否启用 GTID 模式——这是所有操作的分水岭。
怎么快速确认自己是不是 GTID 模式
别猜，直接执行：SHOW VARIABLES LIKE 'gtid_mode';。返回值为 ON 就是 GTID 模式；返回 OFF 才能用传统方式。常见误判点：
- 看到
SHOW SLAVE STATUS\G中Executed_Gtid_Set非空就认为开了 GTID —— 可能是旧从库残留，必须以变量为准 - 主库开 GTID、从库没开，或反之，会导致复制启动失败或中途断裂，1062 往往是连带症状
- 执行
SET GLOBAL sql_slave_skip_counter = 1;报错ERROR 1858或ERROR 1794，说明 GTID 已启用，立刻停手
GTID 模式下跳过 1062 的唯一合法方式
本质是“伪造一个已执行的 GTID”，让 SQL 线程跳过卡点，不是跳过下一条事件。漏掉任一环节都会导致 GTID 集合永久错乱，只能重建从库。
-
STOP REPLICA;（MySQL 8.0.22+ 已弃用SLAVE语法） - 从
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 REPLICA;
跳过之后必须立刻做的三件事
跳过只是恢复同步的起点，不是终点。否则 1062 很可能在下一秒、另一张表再次爆发。
-
查根源：用
mysqlbinlog --base64-output=DECODE-ROWS -v解析报错对应 binlog，确认该INSERT是谁、何时、为何产生；同时在从库执行SELECT * FROM 表名 WHERE 主键 = X;，比对主库是否存在、是否多出一行 -
清脏数据：如果从库存在不该有的记录（如人为误插入），且业务允许，优先执行
SET sql_log_bin = 0; DELETE FROM 表名 WHERE 主键 = X;，再启动复制——比跳过更安全、更可追溯 -
校一致性：跳过或清理后，至少抽样核验关键表：
SELECT COUNT(*), MIN(id), MAX(id) FROM 表名;；或使用pt-table-checksum全量比对
最容易被忽略的致命细节
GTID_NEXT 值抄错一位、COMMIT 前连接断开、或没执行 STOP REPLICA 就设 GTID_NEXT，都会让从库进入不可恢复状态。这不是配置问题，是状态机级损坏——此时没有补救命令，重建从库是唯一选择。
