ERROR 1062是主从数据已实际不一致的明确信号，非临时故障；必须先查gtid_mode确认模式，GTID开启时sql_slave_skip_counter已弃用，须用STOP REPLICA→SET GTID_NEXT→BEGIN;COMMIT→SET GTID_NEXT='AUTOMATIC'→START REPLICA精准跳过，并立即溯源、清理脏数据、校验一致性。
MySQL主从复制报错 ERROR 1062 不是“偶尔卡一下”，而是主从数据已实际不一致的明确信号——它从不单独出现，只在脏数据、误操作或逻辑缺陷已经存在之后才浮出水面。
为什么从库会报1062而主库不报
主库写入时可能用 INSERT IGNORE、ON DUPLICATE KEY UPDATE 或应用层去重，把冲突 quietly 吞掉；但从库是严格按 binlog 重放语句的。如果主库那条 INSERT 实际没插入（被 ignore 掉了），从库 relay log 里却仍要执行一遍，而此时从库本地已有同主键记录，就直接触发 ERROR 1062。
常见诱因包括：
- 人为在从库执行过
INSERT或REPLACE INTO（哪怕只读模式也拦不住误操作） - 主从切换后 GTID 或 position 跳过部分事件，导致从库状态和主库错位
- 主库 binlog_format = STATEMENT 且语句非确定性（如含
NOW()、UUID()），造成主从执行结果不一致
GTID 模式下 sql_slave_skip_counter 为什么总报错
执行 SET GLOBAL sql_slave_skip_counter = 1 报 ERROR 1251 或 ERROR 1858，不是你输错了命令，是 MySQL 8.0.23+ 默认启用 gtid_mode = ON，该变量已被彻底弃用。
必须先确认真实状态：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 运行
SHOW VARIABLES LIKE 'gtid_mode';—— 返回ON就必须走 GTID 跳过路径 - 别信
Executed_Gtid_Set非空就以为开了 GTID，旧从库残留值很常见 - 主库开 GTID、从库没开，或反之，会导致复制启动失败或中途断裂，
1062往往是连带症状
跳过前不查这三件事，等于埋雷
跳过只是让 SQL 线程动起来，不是修复问题。不查清根源，几分钟后可能在另一张表再爆一次 1062。
- 用
mysqlbinlog --base64-output=DECODE-ROWS -v解析报错对应 binlog，确认那条 INSERT 是谁、何时、为何产生 - 在从库执行
SELECT * FROM 表名 WHERE 主键 = X;，再对比主库同条件结果——别假设“主库有，从库就该有” - 检查该表是否真有不该存在的行：如果从库多出一条无业务价值的记录，优先
DELETE FROM 表名 WHERE 主键 = X;，比跳过更安全、更可追溯
最容易被忽略的关键细节
GTID 模式下跳过本质是“伪造一个已执行的 GTID”，靠注入空事务消耗掉冲突事务的 GTID。漏掉任一环节都不可逆：
-
GTID_NEXT值抄错一位、大小写/冒号/引号不匹配，GTID 集合永久错乱 -
BEGIN; COMMIT;必须是空事务，不能带任何 DML；连接在COMMIT前断开，GTID 状态就不完整 - 没执行
STOP REPLICA就设GTID_NEXT，MySQL 会拒绝或静默失败
这些步骤一旦出错，从库将无法自动恢复，只能重建。
