mysql 1062错误是主键或唯一键冲突，本质为违反唯一约束；gtid模式下（8.0.23+默认启用）sql_slave_skip_counter已弃用，须用set gtid_next + begin; commit;伪造空事务跳过，且必须先查根因（如从库误写、主从数据不一致）再操作。
1062 错误不能靠 SET GLOBAL sql_slave_skip_counter = 1 硬跳过——MySQL 8.0.23+ 默认启用 GTID，该命令已被弃用，执行直接报错 ERROR 1251。
为什么 sql_slave_skip_counter 在大多数生产环境已失效
不是你命令输错了，是机制变了。MySQL 8.0.23 起默认开启 gtid_mode=ON，此时 sql_slave_skip_counter 被彻底禁用，强行设置会触发 ERROR 1251: SET GLOBAL sql_slave_skip_counter is not supported when @@GLOBAL.GTID_MODE = ON。
它只在极旧配置下有效：binlog_format = STATEMENT 且 gtid_mode=OFF，而这类环境现在极少见。如果你的 SHOW VARIABLES LIKE 'gtid_mode'; 返回 ON，就别再试这个变量了。
- 查当前模式：
SHOW VARIABLES LIKE 'gtid_mode'; - 确认复制状态：
SHOW SLAVE STATUS\G，重点看Executed_Gtid_Set和Retrieved_Gtid_Set是否非空 - 若
Executed_Gtid_Set有内容，说明已是 GTID 复制，sql_slave_skip_counter完全不生效
GTID 模式下跳过 1062 的正确操作步骤
本质是“伪造一个已执行的事务”，让从库跳过卡住的那个 GTID。必须严格按顺序执行，漏一步或抄错 GTID 都会导致复制永久中断。
- 先停复制：
STOP 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;（这是关键，不是随便执行个语句） - 重置回自动模式：
SET GTID_NEXT = 'AUTOMATIC'; - 重启复制：
START SLAVE;
执行后立刻检查 Seconds_Behind_Master 是否开始下降，并确认 SQL_Thread_State 变为 Slave has read all relay log 或类似正常状态。
跳过前必须做的三件事：别急着执行 SET GTID_NEXT
1062 是症状，不是病因。跳过只是临时止血，不查根因，几分钟后可能在另一张表再爆一次。
- 查主库 binlog 确认那条 INSERT 是谁发的：
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.0000xx | grep -A 5 -B 5 'Duplicate entry.*PRIMARY' - 对比主从数据差异：
SELECT * FROM tbl WHERE id = xxx;分别在主库和从库执行，看字段值是否一致（比如log_result字段从库是 1、主库是 0） - 确认从库是否被误写入：检查
read_only和super_read_only是否都为ON；查审计日志或慢查日志里是否有非复制线程的写操作
如果发现从库多出一条不该有的记录，且业务可接受，优先 DELETE FROM tbl WHERE id = xxx; 再 START SLAVE;——比跳过更安全、副作用更小。
重新同步时为什么别用 mysqldump 直接导入
全量导出再导入看似简单，但在大库上极易引发新问题：锁表时间长、主库负载飙升、字符集/SQL_MODE 不一致导致隐性数据损坏，还可能因 --set-gtid-purged=ON 默认行为导致 GTID 集合错乱。
- 推荐导出命令：
mysqldump --single-transaction --master-data=2 --triggers --routines --set-gtid-purged=OFF - 导入前务必校验：
pt-table-checksum全量比对，或至少抽样比对关键表主键范围和行数 - 真正稳定的重建方式是基于现有从库快照克隆，或使用 MySQL Clone Plugin（8.0.17+）直接拉取主库一致性快照
跳过操作本身不难，难的是判断“该不该跳”——如果错误事务来自应用双写、测试数据残留或幂等缺失，跳过只是把问题往后拖。真正要盯住的，是写入路径是否隔离、binlog_format 是否为 ROW、以及所有从库的 read_only 是否真生效。
