需手动调整auto_increment值至大于当前最大id，执行alter table t auto_increment = n（n > max(id)）并验证生效，replace或on duplicate key update无法解决自增失步问题。
MySQL 插入报错 ERROR 1062 (23000): Duplicate entry 'X' for key 'PRIMARY' 怎么办
这是自增主键（AUTO_INCREMENT）没对齐导致的典型冲突：表里已有 ID=100 的记录，但 auto_increment 值还卡在 95，下一条 INSERT 就会试图插 ID=95，直接撞上已存在主键。
别急着删数据或改表结构。先确认当前状态：
SHOW CREATE TABLE `your_table`;
看输出里 AUTO_INCREMENT 后面的数字，再查最大 ID：
SELECT MAX(id) FROM `your_table`;
如果后者更大，说明 AUTO_INCREMENT 落后了——必须手动拉齐。
- 用
ALTER TABLE your_table AUTO_INCREMENT = N设置，N 必须 > 当前最大 ID（建议 +1） - 不能设成小于等于现有最大 ID 的值，MySQL 会静默忽略（5.7+ 版本），不报错但也不生效
- 执行后立刻
SHOW CREATE TABLE验证是否更新成功，别只信命令没报错
用 REPLACE INTO 或 INSERT ... ON DUPLICATE KEY UPDATE 能绕过 ID 冲突吗
不能。这两种写法本质是“冲突时覆盖”，但前提是 INSERT 语句能生成合法 ID。如果 AUTO_INCREMENT 值本身就在已存在 ID 范围内，还没走到冲突处理逻辑，MySQL 就已经在分配阶段报 ERROR 1062 了。
它们只对“业务逻辑级重复”有效（比如唯一索引冲突），不是自增机制失步的解药。
-
REPLACE INTO是先 DELETE 再 INSERT，ID 会变，可能破坏外键关联或历史追踪 -
INSERT ... ON DUPLICATE KEY UPDATE不改变自增计数器，下次插入仍会沿用旧的AUTO_INCREMENT值 - 真要临时绕过，得显式指定 ID（
INSERT INTO t(id, ...) VALUES (101, ...)），但这要求你全程自己管 ID 分配
为什么 TRUNCATE TABLE 之后 AUTO_INCREMENT 重置为 1，但 DELETE FROM 不重置
因为 TRUNCATE 是 DDL 操作，MySQL 直接重建空表，连 AUTO_INCREMENT 计数器都一并初始化；而 DELETE 是 DML，只删行，计数器纹丝不动——哪怕删光了所有数据。
这正是线上误删后恢复 ID 序列最容易踩的坑：以为清空就“干净”了，结果新插入还是从老计数器继续跑，大概率撞 ID。
- 如果确定要清空并重置 ID，用
TRUNCATE TABLE，但注意它无法回滚、会重置外键约束检查 - 如果只是删部分数据，又想重置计数器，必须手动
ALTER TABLE ... AUTO_INCREMENT = 1（且确保表为空） - InnoDB 表的
AUTO_INCREMENT值在服务重启后可能“回退”到上次持久化的最大 ID，所以别依赖重启自动修复
批量导入数据时 ID 冲突频发，怎么预防
核心是让导入过程和 AUTO_INCREMENT 计数器保持同步。别依赖 MySQL 自动分配，尤其当源数据已有 ID 时。
- 导入前先查
SELECT MAX(id) FROM t，再用ALTER TABLE t AUTO_INCREMENT = N把计数器拨到比最大 ID 大的值 - 如果源数据 ID 是连续且无缺口的，可直接设为
MAX(id) + 批量条数，留足余量 - 用
LOAD DATA INFILE时，若文件含 ID 列，加SET id = NULL让 MySQL 强制走自增逻辑（前提是该列为NOT NULL） - 避免用
mysqldump --skip-auto-increment导出，它会把AUTO_INCREMENT值固化进 SQL，还原时可能覆盖当前值
最麻烦的不是调一次 AUTO_INCREMENT，而是多个应用、定时任务、手动脚本同时往一张表写，谁都没管计数器。这种场景下，ID 冲突几乎是必然的——要么统一收口 ID 分配，要么接受它根本不可靠。
