自增ID冲突本质是AUTO_INCREMENT值未对齐现有数据最大ID，需先查MAX(id)和SHOW CREATE TABLE中的AUTO_INCREMENT值：若前者≥后者则必冲突，须重置；若后者远大于前者则属安全跳号。
迁移后自增ID冲突，本质是目标表的 AUTO_INCREMENT 值没对齐已有数据的最大ID，不是数据本身有问题，而是MySQL“以为下一个可用ID比实际更小”。必须立刻查清当前最大ID和表元数据里的 AUTO_INCREMENT 值是否匹配，再决定是重置、跳过还是改写入逻辑。
怎么确认是不是真冲突而不是误报
跳号不报错，但插入时会直接触发 ERROR 1062 Duplicate entry 'X' for key 'PRIMARY'。先验证是不是“真撞了”：
- 执行
SELECT MAX(id) FROM your_table;查出当前最大ID（比如是999） - 执行
SHOW CREATE TABLE your_table;，看输出里AUTO_INCREMENT=xxx的值（比如是500或2000000） - 如果
AUTO_INCREMENT ≤ MAX(id)（如 500 ≤ 999），下一次无指定ID的INSERT必然失败——这是危险状态，必须重置 - 如果
AUTO_INCREMENT ≫ MAX(id)（如 2000000 ≫ 999），说明是迁移时没带自增值，属于“空洞型跳号”，不影响写入，但可能干扰分页、排序或ID连续性预期
ALTER TABLE AUTO_INCREMENT = N 安全设置的硬条件
这个语句不会修改已有数据，只影响下一条未指定主键的插入，但它有严格前提：
- 必须在低峰期执行，且先加读锁：
FLUSH TABLES WITH READ LOCK;（生产环境慎用，可考虑SET innodb_lock_wait_timeout = 3;防死锁） -
N必须大于当前MAX(id)，推荐设为MAX(id) + 1；若表为空，设为1即可 - InnoDB 表即使删过大量数据，
AUTO_INCREMENT也不会自动回落，必须手动重置；TRUNCATE TABLE虽能重置，但会清空数据，不能用于修复场景 - 执行后务必用
SHOW CREATE TABLE确认是否生效，别只信返回的 “Query OK”
mysqldump 导入后 AUTO_INCREMENT 没生效的常见原因
导出文件末尾本该有类似 ALTER TABLE `t` AUTO_INCREMENT=10001; 的语句，但它常被静默跳过：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 导入时用了
--force参数，遇到语法错误（比如注释格式不对）就跳过整行 - 某些GUI工具或脚本会过滤掉非
INSERT/CREATE开头的语句 - 导出时加了
--skip-auto-increment（明确丢弃自增值），或用了--no-create-info却没补ALTER - 检查导出SQL文件：用
grep "AUTO_INCREMENT=" your_dump.sql确认该行存在且未被注释；缺失就手动加上并重执行
已经报 ERROR 1062 了，怎么救急
错误信息里写的那个ID（比如 '12345'）已经存在，不能强行把 AUTO_INCREMENT 设成更小的值：
- 先查
SELECT * FROM your_table WHERE id = 12345;—— 如果是测试残留或脏数据，可DELETE或UPDATE掉 - 如果该记录是合法业务数据，就必须把
AUTO_INCREMENT设到一个安全值，比如MAX(id) + 100，留出缓冲空间 - 极端情况如ID接近
INT上限（2147483647），别只调AUTO_INCREMENT，得评估是否要升级字段为BIGINT并同步改应用层ID生成逻辑
最常被忽略的一点：你以为只查了本库的 MAX(id) 就够了，但在主从或多节点环境下，必须查所有节点该表的 MAX(id)，取最大值再加1——否则新主库切完第一笔写入就撞上旧从库已存在的ID。
