1062错误是主从数据已实际不一致的明确信号，表明从库存在某记录而主库又发送重复insert/replace触发唯一键冲突；常见原因包括人为直连从库写入、主库与从库sql执行逻辑差异、历史同步遗漏、gtid集合未对齐等。
1062 错误不是复制机制出 bug，而是主从数据已实际不一致的明确信号——它说明从库当前存在某条记录，而主库又发来一条 INSERT/REPLACE，试图写入相同主键或唯一键值。
为什么从库会多出那条冲突记录
常见真实场景包括：
- 人为直连从库执行了
INSERT或REPLACE INTO，比如运维临时修复、开发误操作、脚本未区分读写端口 - 主库执行了
INSERT IGNORE或REPLACE INTO，但从库因 SQL_MODE、字符集、外键约束或触发器行为差异，没走相同逻辑路径 - 历史全量同步时漏掉部分数据，或导入后未清空从库残留测试数据
- 主从切换后 GTID 集合未对齐，导致某事务被重复应用（尤其在
log_slave_updates=OFF的级联架构中）
为什么 binlog_format=ROW 下 sql_slave_skip_counter 无效
ROW 格式下，每个变更都以“行事件”形式记录，sql_slave_skip_counter 是按“事件计数”跳过，但一个事务可能包含多个事件（如 BEGIN + 多行 WRITE_ROWS + COMMIT），跳 1 个事件极易导致后续事件解析错位。MySQL 索性在 GTID 模式下直接禁用该变量，报错 ERROR 1251 或 ERROR 1858。
为什么跳过之后很快又报另一个 1062
这不是偶然，是问题未根治的必然表现：
-
auto_increment_offset和auto_increment_increment在主从间不匹配，导致后续自增 ID 冲突 - 跳过操作本身出错：GTID_NEXT 值抄错一位、
BEGIN; COMMIT;漏写、或 COMMIT 前连接断开，造成 GTID 集合永久错乱 - 从库
read_only=OFF且未设super_read_only=ON，应用或 DBA 仍在持续写入 - 主库开了
binlog_format=STATEMENT并用了NOW()、UUID()等非确定性函数，导致主从重放结果不一致
最常被忽略的检查点：gtid_mode 状态真假
很多人看到 SHOW SLAVE STATUS\G 中 Executed_Gtid_Set 非空，就以为开了 GTID——其实可能是旧从库残留值。真正判断依据只有：SHOW VARIABLES LIKE 'gtid_mode'; 返回 ON 才算真开启。一旦误判，用 SET GLOBAL sql_slave_skip_counter = 1 就会直接触发 ERROR 1794，让复制彻底卡死。
