GTID模式下跳过1062错误必须先确认gtid_mode=ON，再用SET GTID_NEXT+空事务伪造GTID，严禁用sql_slave_skip_counter；跳过后须查源头、清脏数据、校验一致性，漏一步即导致从库状态机损坏。
先确认 gtid_mode 是否真开启
别看 Executed_Gtid_Set 非空就以为开了 GTID——旧从库残留值很常见。SHOW VARIABLES LIKE 'gtid_mode' 才是唯一权威依据。返回 ON 才能走 GTID 跳过流程；返回 OFF 却硬套 GTID 步骤，后续所有操作都会失效甚至损坏状态机。
跳过 1062 主键冲突必须用 SET GTID_NEXT + 空事务
SET GLOBAL sql_slave_skip_counter = 1 在 GTID 模式下直接报错 ERROR 1858，不是“不推荐”，是根本不可用。正确做法是伪造已执行那个卡住的 GTID：
- 从
SHOW SLAVE STATUS\G的Last_SQL_Error字段提取完整 GTID，例如gtid:3e11fa47-71ca-11e1-9e33-c80aa9429562:23（注意冒号前后无空格、大小写严格一致） - 执行顺序不能乱：
STOP SLAVE;→SET GTID_NEXT = '3e11fa47-71ca-11e1-9e33-c80aa9429562:23';→BEGIN; COMMIT;→SET GTID_NEXT = 'AUTOMATIC';→START SLAVE; -
BEGIN; COMMIT;必须是空事务，不能带任何 DML；且COMMIT前连接不能断开，否则 GTID 集合永久错乱
跳过之后三件事不做等于白跳
跳过只是让 SQL 线程继续跑，不是修复数据。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是否主从匹配
最容易被忽略的致命细节
漏一步、抄错一位、STOP SLAVE 没执行就设 GTID_NEXT、或只停了 SQL_THREAD 却没停 IO_THREAD（MySQL 8.0.22+ 推荐明确停 SQL_THREAD），都会让从库进入不可恢复状态。这不是配置问题，是 GTID 状态机级损坏——只能重建从库。
