1062错误必须先确认GTID模式：执行SHOW VARIABLES LIKE 'gtid_mode'，返回ON即为GTID模式；GTID下严禁用sql_slave_skip_counter，须用SET GTID_NEXT注入空事务跳过，且必须严格按STOP SLAVE SQL_THREAD、SET GTID_NEXT、BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC'; START SLAVE顺序执行，缺一不可。
1062 错误不能靠“跳过”一劳永逸，必须先确认 GTID 模式是否启用——这是所有操作的分水岭。 盲目执行 SET GLOBAL sql_slave_skip_counter = 1 在 GTID 模式下会直接报错，且导致复制永久断裂；而跳过之后若不查源头，下一次 1062 几乎必然重现。
怎么快速判断自己是不是 GTID 模式
执行 SHOW VARIABLES LIKE 'gtid_mode';，返回值为 ON 就是 GTID 模式。再补一句 SHOW MASTER STATUS\G，看 Executed_Gtid_Set 是否非空，双重验证更稳。如果看到错误提示 ERROR 1794 (HY000): The slave is configured with slave_exec_mode = IDENTITY but GTID mode is enabled，说明你已经在 GTID 模式下硬用了老命令，得立刻停手。
GTID 模式下跳过 1062 的唯一合法方式
必须用 SET GTID_NEXT 注入空事务，本质是“伪造已执行”，让复制线程认为那个冲突事务已完成。步骤缺一不可：
- 先停 SQL 线程：
STOP SLAVE SQL_THREAD; - 查出错事务 GTID：从
SHOW SLAVE STATUS\G的Last_SQL_Error或Retrieved_Gtid_Set与Executed_Gtid_Set差集中提取，例如3e11fa47-71ca-11e1-9e33-c80aa9429562:23 - 严格执行三步：
SET GTID_NEXT='3e11fa47-71ca-11e1-9e33-c80aa9429562:23'; BEGIN; COMMIT; - 重置并启动：
SET GTID_NEXT='AUTOMATIC'; START SLAVE;
抄错一位字符、漏掉 BEGIN; COMMIT;、或在 COMMIT 前断开连接，都会让从库 GTID 状态永久错乱——此时重建从库是唯一选择。
非 GTID 模式（binlog position）下跳过要点
传统模式下才能用 sql_slave_skip_counter，但仍有强约束：
- 必须先停 SQL 线程：
STOP SLAVE SQL_THREAD; - 仅对
binlog_format = STATEMENT稳定有效；ROW格式下该命令无效，还会报ERROR 1374 - 它跳的是“下一条事件”，不是“当前错误那条”，容易引发后续数据错位
- 更稳妥的做法是定位中继日志位置：
Relay_Master_Log_File和Exec_Master_Log_Pos，用mysqlbinlog解析确认冲突 SQL，再决定是删从库脏数据，还是手动执行修复语句
别碰 slave-skip-errors = 1062 配置项——它需重启 MySQL，线上不可行，且会掩盖所有 1062，让不一致静默扩大。
比跳过更重要的事：定位和修复源头
1062 是症状，不是病因。跳过只是临时止血，真正要盯紧的是写入路径：
- 检查从库是否真处于只读：
SELECT @@read_only;，并确认没被应用绕过（比如 ORM fallback 到从库写入） - 查审计日志（
general_log或 Percona 扩展 slow-log），定位那条在从库重复插入的语句来源 - 确认主库
log_slave_updates是否开启——级联复制场景下若关闭，中间从库无法生成正确 GTID，也会诱发 1062 - 对比主从
auto_increment_increment和auto_increment_offset，偏移不一致会导致后续 INSERT 冲突
频繁出现 1062，说明写入隔离已失效。这时候调参数不如查日志，修配置不如砍掉非法写入路径。
