必须先确认GTID模式：执行SHOW VARIABLES LIKE 'gtid_mode'，返回ON即为GTID模式，此时sql_slave_skip_counter失效，须用SET GTID_NEXT注入空事务跳过，并溯源修复数据差异。
直接跳过 ERROR 1062 不解决问题，只会让不一致沉淀——必须先确认是否启用 GTID，再选对方法，最后必须查清并修复数据差异。
怎么快速判断是不是 GTID 模式
别猜，执行这句：SHOW VARIABLES LIKE 'gtid_mode';。返回 ON 就是 GTID 模式，OFF 才是传统 position 模式。很多误操作都源于没确认这点：
- 看到
Executed_Gtid_Set非空就以为开了 GTID？错——旧从库残留值可能还在，必须以变量为准 - 执行
SET GLOBAL sql_slave_skip_counter = 1报ERROR 1251或ERROR 1858？说明 GTID 已开，命令彻底禁用 - 主库开了 GTID、从库没开，或反之，会导致复制断裂，
1062往往是连带症状
GTID 模式下跳过冲突事务（MySQL 8.0.23+ 默认场景）
本质是“伪造一个已执行的 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，或者应用层双写主从。这时候查 SQL 审计日志，比调参数重要得多。
