“key 1”指表中第一个唯一性索引（PRIMARY KEY或首个UNIQUE KEY），需执行SHOW INDEX FROM table_name确认Key_name和Column_name，若为uk_email和email则冲突在email列，与id无关。
查清“key 1”到底指哪个索引
报错里的 key 1 不是主键代称，而是表里第一个唯一性索引（PRIMARY 或任意 UNIQUE KEY）的序号。很多人一看到 Duplicate entry 'alice@example.com' for key 1 就去调 AUTO_INCREMENT，结果发现冲突根本不在主键上。
必须立刻执行：SHOW INDEX FROM table_name，看输出中 Key_name 是 PRIMARY 还是类似 uk_email 的名字，再确认对应 Column_name 字段。如果第一行是 Key_name = uk_email、Column_name = email，那冲突就发生在 email 列，和 id 完全无关。
- 复合唯一索引（如
(user_id, order_date)）要查组合值，单查user_id没用 -
DESCRIBE table_name不显示索引信息，不能替代SHOW INDEX - ORM 自动生成的迁移可能悄悄加了唯一索引，开发时未必意识到
区分是主从数据不一致，还是自增ID没对齐
同样是 ERROR 1062，根源完全不同：前者是数据已脏（比如从库被误写），后者是 AUTO_INCREMENT 计数器在主从间错位——但 SHOW SLAVE STATUS 的 Exec_Master_Log_Pos 只表示 binlog 位置追平，不反映计数器状态。
典型现象：
- 新主库刚切完，第一笔插入就报错 → 大概率是自增ID没校准
- 从库 SQL 线程卡在某条
INSERT，错误日志反复出现相同 ID → 很可能是自增冲突 - 主库没动，但从库突然开始报重复 → 往往是人为在从库直连写入过
验证方式：在从库执行 SELECT MAX(id) FROM tbl_name，再对比主库同表的 MAX(id)。如果从库值 ≤ 主库值，且 SHOW CREATE TABLE 显示 AUTO_INCREMENT 小于等于该最大值，就是计数器落后。
GTID 模式下跳过错误的正确姿势
SET GLOBAL sql_slave_skip_counter = 1 在 GTID 模式下直接报错：ERROR 1858 (HY000): sql_slave_skip_counter can not be set when the server is running with @@GLOBAL.GTID_MODE = ON。必须用空事务注入。
操作链必须严格按顺序：
- 从
SHOW SLAVE STATUS\G的Last_SQL_Error中精确提取 GTID（如3e11fa47-71ca-11e1-9e33-c80aa9429562:23，冒号前后无空格、大小写严格一致） STOP REPLICA;SET GTID_NEXT = 'xxx:yyy';BEGIN; COMMIT;SET GTID_NEXT = 'AUTOMATIC';START REPLICA;
跳过后必须校验数据一致性——跳过只是恢复同步，不是修复差异。
自增ID校准三步不能省
别先想着跳过或重放 binlog。自增冲突必须停写、校准、配对改配置，否则下次切主还会爆。
- 暂停所有写入（尤其应用层双写、跨库直连）
- 查出所有节点上该表的
MAX(id)，取最大值 +1 作为目标值N - 在即将升主的从库上执行：
ALTER TABLE tbl_name AUTO_INCREMENT = N;，然后用SHOW CREATE TABLE确认是否生效
注意：mysqldump --insert-ignore 或导入时加 --force 不会更新表元数据里的当前计数器，后续插入仍会撞。校准动作必须显式执行 ALTER TABLE。
