ERROR 1062是主从数据已实际不一致的明确信号，须先确认gtid_mode状态：若为ON，则禁用sql_slave_skip_counter，必须用SET GTID_NEXT+BEGIN;COMMIT;注入空事务精准跳过，并溯源修复根因、校验一致性。
MySQL主从复制报错 ERROR 1062（Duplicate entry）不是可忽略的临时异常，而是主从数据已实际不一致的明确信号。所谓“平滑自愈”，不等于跳过就完事——它要求在最小干预前提下精准定位、安全跳过、并同步根治源头，避免问题复发。关键在于：先确认是否启用 GTID，再选对方法，最后必须验证一致性。
第一步：确认复制模式，避开已失效操作
执行以下命令，以变量值为准：
-
SHOW VARIABLES LIKE 'gtid_mode'; —— 若返回
ON，说明已启用 GTID，sql_slave_skip_counter完全禁用，任何尝试都会触发ERROR 1251或ERROR 1858 -
SHOW SLAVE STATUS\G —— 查看
Executed_Gtid_Set和Retrieved_Gtid_Set是否非空；若两者有差值，且gtid_mode=ON，则必须走 GTID 跳过流程 - 切勿依赖
Seconds_Behind_Master = NULL判断中断——真正需关注的是Slave_SQL_Running: No和Last_SQL_Error字段内容
第二步：GTID 模式下精准跳过冲突事务（推荐且主流）
这是当前 MySQL 8.0.23+ 默认环境下的唯一合规方式。本质是“伪造一个已执行的 GTID”，让 SQL 线程跳过卡点，而非跳过下一条事件。
- 从
Last_SQL_Error中提取完整 GTID，例如：gtid:3e11fa47-71ca-11e1-9e33-c80aa9429562:23（注意冒号前后无空格、大小写严格一致） - 按顺序执行以下五步（缺一不可）：
STOP SLAVE;SET GTID_NEXT = '3e11fa47-71ca-11e1-9e33-c80aa9429562:23';BEGIN; COMMIT;（必须是空事务，不能带任何 DML）SET GTID_NEXT = 'AUTOMATIC';START SLAVE; - 执行后立即检查：
Slave_SQL_Running: Yes、Seconds_Behind_Master开始下降、SQL_Thread_State变为Slave has read all relay log或类似正常状态
第三步：跳过之后必须做的三件事
跳过只是恢复同步的起点，不是终点。否则 1062 很可能在下一秒、另一张表再次爆发。
-
查根源：用
mysqlbinlog --base64-output=DECODE-ROWS -v解析报错对应 binlog，确认该 INSERT 是谁、何时、为何产生；同时在从库执行SELECT * FROM 表名 WHERE 主键 = X;，比对主库是否存在、是否多出一行 -
清脏数据：如果从库存在不该有的记录（如人为误插入），且业务允许，优先
DELETE FROM 表名 WHERE 主键 = X;，再启动复制——比跳过更安全、更可追溯 -
校一致性：跳过或清理后，至少抽样核验关键表：
SELECT COUNT(*), MIN(id), MAX(id) FROM 表名;；有条件务必运行pt-table-checksum全量比对
第四步：长期防复发的关键配置
很多 1062 冲突本可避免。运维层面需加固以下几项：
- 从库强制只读：
read_only = ON+super_read_only = ON（防止超级用户误写） - 主库 binlog 格式设为
ROW（默认且推荐），禁用非确定性语句（如NOW()、UUID()在 STATEMENT 模式下极易引发主从偏差） - 多写场景（如双主、分片）必须统一配置
auto_increment_increment和auto_increment_offset，避免自增主键撞车 - 开启
enforce_gtid_consistency = ON，确保所有操作兼容 GTID，杜绝隐性不一致风险
