直接跳过error 1062是埋雷，必须先定位冲突根因：查清“key 1”对应的实际索引字段、区分自增未对齐还是从库脏数据、gtid模式下禁用sql_slave_skip_counter、alter table重复错误需查长事务或切copy模式，修复前务必切断所有向从库的写入。
直接跳过 ERROR 1062 不是修复，是埋雷。它明确告诉你：主从数据已不一致，必须先定位冲突根因，再决定是校准自增、清理脏数据，还是精准跳过单事务——选错路径，后续会反复报错甚至扩散到其他表。
查清“key 1”到底对应哪个索引字段
报错里写的 for key 'PRIMARY' 或 for key 1 并不总代表主键。MySQL 按索引定义顺序编号，“key 1” 是表中第一个唯一性索引（可能是 PRIMARY KEY，也可能是第一个 UNIQUE KEY）。
- 执行
SHOW INDEX FROM table_name;，看Key_name为PRIMARY或UNIQUE的第一行，记下它的Column_name - 若
Column_name是email，那Duplicate entry 'test@example.com' for key 1就是邮箱重复，和主键id无关 - 复合唯一索引（如
(user_id, order_date)）要查组合值：SELECT user_id, order_date FROM orders WHERE user_id = X AND order_date = '2026-09-30';
区分是自增ID没对齐，还是人为写入脏数据
这是修复路径的分水岭。前者必须停写、校准 AUTO_INCREMENT 值；后者得先清理从库上多出来的那条记录，否则跳过一次，下次 INSERT 还撞。
- 查从库该表当前最大 ID：
SELECT MAX(id) FROM tbl_name;，再查SHOW TABLE STATUS LIKE 'tbl_name';中的Auto_increment值 - 如果
Auto_increment ，说明自增计数器已落后，下一次 <code>INSERT必然撞 —— 这是典型自增未对齐，不是跳过能解决的 - 如果
Auto_increment > MAX(id)，但错误日志里明确出现INSERT INTO ... VALUES (10086, ...)，而你确认主库没这条记录，大概率是从库被误写入过 - GTID 模式下，
Exec_Master_Log_Pos追平 ≠ 数据一致，AUTO_INCREMENT计数器完全独立，重启也不同步
GTID 开启时严禁用 sql_slave_skip_counter
这个命令在 GTID 模式下不仅无效，还会触发 ERROR 1858 或 ERROR 1251，强行设置等于阻断复制恢复流程。
- 先停 SQL 线程：
STOP SLAVE SQL_THREAD; - 从
SHOW SLAVE STATUS\G中提取出错事务的 GTID（看Retrieved_Gtid_Set和Executed_Gtid_Set差集，或直接看Last_SQL_Error_Timestamp附近日志） - 执行三步占位：
SET GTID_NEXT = 'xxx:yyy'; BEGIN; COMMIT; SET GTID_NEXT = 'AUTOMATIC';，然后START SLAVE; - 注意：
GTID_NEXT必须大小写、冒号、分号全对，且只能设一次；设完不执行BEGIN; COMMIT;，启动后仍会重试原事务
ALTER TABLE 报 Duplicate entry 别急着改表结构
这个错误常发生在 ADD COLUMN 或 ADD INDEX 期间，根本原因不是数据重复，而是 MySQL Online DDL 在缓存 DML 后回放时才做主键校验——所以你 SELECT 表里根本找不到重复值。
- 别反复重试同一
ALTER，会累积更多缓存 DML，失败概率更高 - 查长事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW()) - TIME_TO_SEC(TRX_STARTED) > 60;，杀掉它们能降低风险 - 紧急时可临时切 COPY 模式：
SET SESSION alter_algorithm = 'COPY';，但会锁表 - 生产环境首选
pt-online-schema-change，它不依赖 MySQL 原生 Online DDL，用触发器+分块拷贝，天然避开“缓存回放冲突”陷阱
最易被忽略的一点：所有修复操作前，必须确认应用层是否还在双写、跨库直连或定时任务往从库写数据。只要写入不停，任何校准或跳过都是徒劳——先掐断源头，再动手。
