必须先执行SHOW VARIABLES LIKE 'gtid_mode'确认模式，返回ON则必须用SET GTID_NEXT注入空事务跳过1062错误，严禁使用sql_slave_skip_counter；返回OFF才可考虑传统方式，且跳过仅为临时恢复，须立即查源头、清脏数据、校验一致性。
先确认是不是 GTID 模式，否则所有操作都白忙
执行 SHOW VARIABLES LIKE 'gtid_mode'; —— 如果返回 ON，你就必须走 GTID 跳过流程；返回 OFF 才能考虑传统方式。别信 Executed_Gtid_Set 非空就以为开了 GTID，旧从库残留值很常见，gtid_mode 才是唯一权威依据。如果执行 SET GLOBAL sql_slave_skip_counter = 1; 报错 ERROR 1794 或 ERROR 1858，说明 GTID 已启用，立刻停手。
GTID 模式下跳过 1062 的五步缺一不可
本质是“伪造已执行”那个卡住的 GTID，不是跳过下一条事件。漏一步或抄错字符，GTID 集合就永久错乱，只能重建从库：
-
STOP SLAVE;（MySQL 8.0.22+ 推荐用STOP REPLICA;） - 从
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，且 COMMIT 前不能断开连接） SET GTID_NEXT = 'AUTOMATIC'; START SLAVE;
跳过之后三件事不能省，否则 1062 几分钟内复现
跳过只是恢复同步的起点，不是终点：
- 查源头：用
mysqlbinlog --base64-output=DECODE-ROWS -v解析报错对应 binlog，确认那条 INSERT 是谁、何时、为何发到从库（比如应用双写、从库误开read_only = OFF） - 清脏数据：如果从库多出的记录是人为误插，且业务允许，优先执行
SET sql_log_bin = 0; DELETE FROM 表名 WHERE 主键 = X;，比跳过更安全、可追溯 - 校一致性：至少抽样核验关键表主键范围，有条件务必跑
pt-table-checksum全量比对
别碰 slave-skip-errors = 1062 这类配置项
它需重启 MySQL，线上不可行；而且只对新错误生效，对当前卡住的事务完全无效。更危险的是，它会掩盖所有 1062，让不一致静默扩大——你可能第二天才发现几十张表都错了。真正要盯紧的是写入源头，比如检查 SELECT @@read_only; 是否为 ON，再翻 audit log 或 general_log，定位那条在从库重复插入的语句到底从哪来。
GTID_NEXT 值抄错一位、COMMIT 前连接断开、或没执行 STOP SLAVE 就设 GTID_NEXT，都会让从库进入不可恢复状态。这不是配置问题，是状态机级损坏。 
