gtid模式下跳过error 1062需先确认gtid_mode=on，再执行stop replica、set gtid_next、空事务、set gtid_next=automatic、start replica；跳过仅恢复同步，必须查根源、清脏数据、校验一致性并隔离写入路径。
直接跳过 ERROR 1062 不解决问题，它只是主从数据已实际不一致的明确信号。必须先确认是否启用 GTID 模式，再选对方法，最后必须查清并修复数据差异。
怎么快速判断自己是不是 GTID 模式
别猜，执行：SHOW VARIABLES LIKE 'gtid_mode';。返回 ON 就是 GTID 模式；返回 OFF 才能用传统 position 方式处理。常见误判点包括：
- 看到
SHOW SLAVE STATUS\G中Executed_Gtid_Set非空就认为开了 GTID —— 实际可能是旧从库残留值，必须以变量为准 - 执行
SET GLOBAL sql_slave_skip_counter = 1报ERROR 1858或ERROR 1794，说明 GTID 已启用，该命令彻底失效 - 主库开 GTID、从库没开，或反之，会导致复制启动失败或中途断裂，
1062往往是连带症状
GTID 模式下跳过 1062 的唯一合法方式
本质是“伪造一个已执行的 GTID”，让 SQL 线程跳过卡点。漏掉任一环节都会导致 GTID 集合永久错乱，只能重建从库。操作顺序不可调换：
- 先停 SQL 线程：
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;，比对主库是否存在、是否多出一行 -
清脏数据：如果从库存在不该有的记录（如人为误插入），且业务允许，优先
DELETE FROM 表名 WHERE 主键 = X;，再启动复制——比跳过更安全、更可追溯 -
校一致性：跳过或清理后，至少抽样核验关键表：
SELECT COUNT(*), MIN(id), MAX(id) FROM 表名;；或使用pt-table-checksum全量比对
最容易被忽略的是：跳过操作本身不修复数据，而 1062 总是重复出现，说明写入路径没隔离——比如从库没真正启用 read_only=ON，或者应用层双写主从。这时候查 SQL 审计日志，比调参数重要得多。
