error 1062 是因 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，下次 INSERT 就会尝试插 id = 100，直接撞上已存在记录。
必须分两步确认再修正：
- 查真实最大值：
SELECT MAX(id) FROM table_name - 查当前自增值：
SHOW TABLE STATUS LIKE 'table_name'，看Auto_increment字段 - 如果前者 ≥ 后者，执行：
ALTER TABLE table_name AUTO_INCREMENT = <max></max>
注意：ALTER TABLE ... AUTO_INCREMENT = N 中的 N 必须严格大于当前最大 id；设小了 MySQL 会静默忽略（5.7+），不报错也不生效。
批量导入时手动指定 id 导致冲突怎么清理
常见于 LOAD DATA INFILE 或显式写死 INSERT INTO t(id, ...) VALUES (1001, ...)。此时冲突不是自增错位，而是人为覆盖了未来可能生成的值。
已导入出错时，别急着删全表：
- 先定位真正重复行：
SELECT id, COUNT(*) FROM table_name GROUP BY id HAVING COUNT(*) > 1 - 去重推荐保留最小
id对应记录：DELETE t1 FROM table_name t1 INNER JOIN table_name t2 WHERE t1.id > t2.id AND t1.id = t2.id - 导入前务必确认目标表是否为空；若非空，先查
SELECT MAX(id) FROM table_name，再确保导入数据中所有id都 > 这个值
手动指定 id 是高风险操作，除非迁移历史 ID 等强业务理由，否则应避免。
主从环境恢复后从库自增偏移怎么校准
主库导出 + 从库导入后，从库 Auto_increment 可能比主库小。后续主库新写入同步到从库时，可能因 id 重叠触发隐性冲突（尤其在 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE 场景下不报错但逻辑错乱）。
不能直接在从库执行 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模式能大幅减少这类问题，但跨库合并、多源复制仍需人工核对自增范围
校准前务必分别在主从执行 SHOW TABLE STATUS 对比 Auto_increment 值——差值就是隐患点。
为什么 TRUNCATE 后 AUTO_INCREMENT 重置而 DELETE 不重置
TRUNCATE TABLE 是 DDL 操作，MySQL 直接重建空表，连 AUTO_INCREMENT 计数器都一并初始化；DELETE FROM 是 DML，只删行，计数器纹丝不动——哪怕删光了所有数据。
这是线上误删后恢复 ID 序列最容易踩的坑：
- 以为清空就“干净”了，结果新插入还是从老计数器继续跑，大概率撞
id - 如果确定要清空并重置
id，用TRUNCATE TABLE，但注意它无法回滚、会重置外键约束检查 - 如果只是删部分数据又想重置计数器，必须手动
ALTER TABLE table_name AUTO_INCREMENT = 1，且确保表为空（否则 MySQL 会自动向上取整到大于等于现存最大id+ 1 的值）
真正危险的是人为干预后的“隐性不一致”：比如手动执行过 ALTER TABLE t AUTO_INCREMENT = 500，而表中已有 id = 1000 的记录。MySQL 不报错，但后续插入必然冲突——这种问题不会在重启时暴露，而是在某次正常 INSERT 时突然炸出来。
