直接原因是AUTO_INCREMENT值未随实际数据重置，必须先查MAX(id)和SHOW TABLE STATUS中的Auto_increment，若前者≥后者，则执行ALTER TABLE table_name AUTO_INCREMENT = MAX(id)+1。
恢复数据后插入报 ERROR 1062 怎么办
直接原因是表的 AUTO_INCREMENT 值没跟着实际数据重置，比如你导入了 id 最大为 999 的数据，但表状态里 Auto_increment 还是 100，下次插入就会撞上已存在的 100～999。这不是“数据重复”，而是“自增序列错位”。
- 先查真实最大值：
SELECT MAX(id) FROM table_name - 再查当前自增值：
SHOW TABLE STATUS LIKE 'table_name'，看Auto_increment字段 - 如果前者 ≥ 后者，必须重置：
ALTER TABLE table_name AUTO_INCREMENT = <MAX(id)+1>
注意：该语句只生效于下一次 INSERT，且不能小于当前最大主键值（MySQL 会自动向上取整到大于等于 max(id)+1 的最小合法值）。
批量导入时手动指定 id 导致冲突怎么清理
常见于从旧库导出 CSV 再 LOAD DATA INFILE，或用 INSERT ... VALUES (1001, ...) 显式写死 id。此时冲突不是自增错，而是人为覆盖了未来可能生成的值。
- 导入前务必确认目标表是否为空；若非空，先
SELECT MAX(id) FROM table_name，再确保导入数据中所有 id 都 > 这个值 - 若已导入并报错，别急着删数据——先用
SELECT id, COUNT(*) FROM table_name GROUP BY id HAVING COUNT(*) > 1找出真正重复的行 - 去重时慎用
DELETE，推荐保留MIN(id)或MAX(id)对应的记录，例如：DELETE t1 FROM table_name t1 INNER JOIN table_name t2 WHERE t1.id > t2.id AND t1.id = t2.id
手动指定 id 是高风险操作，除非有强业务理由（如迁移历史 ID），否则应避免。
主从环境恢复后从库自增偏移怎么校准
主库导出数据 + 从库导入后，从库 AUTO_INCREMENT 可能比主库小，后续主库写入新数据同步到从库时，就可能因 id 重叠触发冲突（尤其在 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE 场景下不报错但逻辑错乱）。
- 检查主从自增值是否一致：
SHOW TABLE STATUS分别在主从执行，对比Auto_increment - 若从库偏小，不能直接
ALTER TABLE ... AUTO_INCREMENT = X—— 必须同时设置auto_increment_offset和auto_increment_increment，确保后续生成不重叠 - 更稳妥的做法：恢复前在从库停写、设
read_only = ON，导入后用STOP SLAVE; SET GLOBAL auto_increment_offset = N; START SLAVE;（N 需与主库 offset 错开）
GTID 模式下这类问题大幅减少，但不等于免疫——跨库合并、多源复制仍需人工核对自增范围。
为什么重置 AUTO_INCREMENT 后还是插入失败
最常被忽略的一点：InnoDB 表的 AUTO_INCREMENT 计数器是内存态的，重启 mysqld 后会从表中找最大值重新初始化。如果你刚 ALTER TABLE ... AUTO_INCREMENT = 1000，又立刻重启，它可能又回到 100（因为表里最大 id 是 99）。
- 验证方式：重启后立即执行
SHOW TABLE STATUS，确认Auto_increment是否仍为你设的值 - 根本解法：确保导入完成后再设值，并避免中途重启；或者改用
innodb_autoinc_lock_mode = 2（交错模式），降低并发插入时的预分配偏差 - 极端情况（如误删大量数据后自增卡住）：可临时用
INSERT INTO table_name (id, ...) VALUES (999999, ...) ON DUPLICATE KEY UPDATE ...“踢一脚”让计数器跳到高位，再ALTER回正常起点
自增主键不是黑盒，它的行为受存储引擎、配置、甚至服务器生命周期影响——恢复数据时，必须把它当作一个需要显式管理的状态变量，而不是默认可靠的计数器。
