必须先执行SHOW VARIABLES LIKE 'gtid_mode'确认是否为ON，是则需按STOP REPLICA SQL_THREAD、提取GTID、SET GTID_NEXT、BEGIN/COMMIT空事务、重置并START REPLICA SQL_THREAD五步操作，跳过仅为起点，须立即溯源查因、清脏数据、校验一致性。
直接跳过 ERROR 1062 是高风险操作，不是“执行一条命令就完事”，而是必须先确认 gtid_mode 状态、精准提取 GTID、注入空事务，并立刻溯源修复数据差异。跳错一步，从库 GTID 集合永久错乱，只能重建。
怎么快速确认是不是 GTID 模式？
别看 Executed_Gtid_Set 是否非空——旧从库残留值很常见，它不作数。唯一权威依据是：
SHOW VARIABLES LIKE 'gtid_mode';
返回 ON 就必须走 GTID 跳过流程；返回 OFF 才能考虑传统方式。如果执行 SET GLOBAL sql_slave_skip_counter = 1; 报 ERROR 1858 或 ERROR 1794，说明 GTID 已启用，立刻停手。
GTID 模式下跳过 1062 的五步缺一不可
本质是“伪造已执行”那个卡住的 GTID，不是跳过下一条事件。漏一步或抄错一位字符，GTID 集合就永久错乱。
- 先停 SQL 线程：
STOP REPLICA SQL_THREAD;（MySQL 8.0.22+ 推荐用REPLICA，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 几分钟内复现
跳过只是恢复同步的起点，不是终点。
- 查根源：用
mysqlbinlog --base64-output=DECODE-ROWS -v解析报错对应 binlog，确认那条INSERT是谁、何时、为何产生；同时在从库执行SELECT * FROM 表名 WHERE 主键 = X;，比对主库是否存在、是否多出一行 - 清脏数据：如果从库存在不该有的记录（如人为误插入），且业务允许，优先执行
SET sql_log_bin = 0; DELETE FROM 表名 WHERE 主键 = X;—— 比跳过更安全、更可追溯 - 校一致性：至少抽样核验关键表主键范围：
SELECT COUNT(*), MIN(id), MAX(id) FROM 表名;；有条件务必跑pt-table-checksum全量比对
最常被忽略的是：GTID_NEXT 值抄错一位、COMMIT 前连接断开、或没执行 STOP REPLICA SQL_THREAD 就设 GTID_NEXT，都会让从库进入不可恢复状态。这不是配置问题，是状态机级损坏。
