必须先执行show variables like 'gtid_mode'确认为on，否则跳过操作将导致gtid状态永久错乱；返回on才是gtid模式，off才可用传统方式，executed_gtid_set非空不等于启用gtid。
必须先执行 SHOW VARIABLES LIKE 'gtid_mode' 确认是否为 ON，否则所有跳过操作都可能让从库 GTID 状态永久错乱，只能重建。
怎么快速判断自己是不是 GTID 模式
别看 Executed_Gtid_Set 非空就下结论——旧从库残留值很常见，gtid_mode 变量才是唯一权威依据。执行：SHOW VARIABLES LIKE 'gtid_mode'，返回 ON 就是 GTID 模式；返回 OFF 才能考虑传统方式。
常见误判点：
- 执行
SET GLOBAL sql_slave_skip_counter = 1报ERROR 1858或ERROR 1794，说明 GTID 已启用，立刻停手 - 主库开 GTID、从库没开，或反之，会导致复制启动失败或中途断裂，
1062往往是连带症状
GTID 模式下跳过 1062 的五步缺一不可
本质是“伪造一个已执行的 GTID”，让 SQL 线程跳过卡点。漏一步、抄错一位、或 COMMIT 前连接断开，GTID 集合就永久错乱，只能重建从库。
- 先停 SQL 线程：
STOP REPLICA SQL_THREAD（MySQL 8.0.22+ 推荐，SLAVE已弃用） - 从
SHOW SLAVE STATUS\G的Last_SQL_Error字段提取完整 GTID，形如3e11fa47-71ca-11e1-9e33-c80aa9429562:23（冒号前后无空格、大小写严格一致） - 设 GTID_NEXT：
SET GTID_NEXT = '3e11fa47-71ca-11e1-9e33-c80aa9429562:23' - 执行空事务：
BEGIN; COMMIT;（不能带任何 DML，且COMMIT前连接不能断） - 重置并重启：
SET GTID_NEXT = 'AUTOMATIC'; START REPLICA SQL_THREAD
跳过之后三件事不能省，否则 1062 几分钟内复现
跳过只是恢复同步的起点，不是终点。不查根源，下一次 1062 很可能在另一张表爆发。
-
查根源：用
mysqlbinlog --base64-output=DECODE-ROWS -v解析报错对应 binlog，确认那条INSERT是谁、何时、为何产生；同时在从库执行SELECT * FROM 表名 WHERE 主键 = X，比对主库是否存在、是否多出一行 -
清脏数据：如果从库存在不该有的记录（如人为误插入），且业务允许，优先执行
SET sql_log_bin = 0; DELETE FROM 表名 WHERE 主键 = X，比跳过更安全、可追溯 -
校一致性：至少抽样核验关键表主键范围，有条件务必跑
pt-table-checksum全量比对；特别注意auto_increment_offset和auto_increment_increment是否主从匹配
最常被忽略的一点：GTID_NEXT 值抄错一位、COMMIT 前连接断开、或没执行 STOP REPLICA SQL_THREAD 就设 GTID_NEXT，都会让从库进入不可恢复状态——这不是配置问题，是状态机级损坏。
