报错“duplicate entry '2147483647'”本质是自增id达int有符号上限导致循环冲突，须立即查字段类型（column_type）和真实最大id（max(id)），比对理论上限判断属虚高还是真耗尽；虚高可重置auto_increment为max(id)+1，真耗尽需升级bigint并同步外键、应用层及手动设新起始值。
查清当前自增字段类型和最大ID值
报错 ERROR 1062 (23000): Duplicate entry '2147483647' for key 'PRIMARY' 不代表真有重复数据，而是自增器卡在 INT 有符号上限后反复尝试插入同一值。必须立刻确认两件事：字段实际类型、表中已用到的最大 ID。
执行这两条语句：
-
SELECT COLUMN_NAME, DATA_TYPE, COLUMN_TYPE, EXTRA FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'your_table' AND EXTRA LIKE '%auto_increment%';—— 看COLUMN_TYPE，比如int(11)或int(10) unsigned -
SELECT MAX(id) FROM your_table;—— 拿到真实最大值，和理论上限比对（int有符号是 2147483647，int unsigned是 4294967295）
注意：int(11) 的 “11” 只是显示宽度，和取值范围完全无关；别只看 SHOW TABLE STATUS 里的 AUTO_INCREMENT 值——它可能因批量删除虚高，但真正致命的是 MAX(id) 是否逼近类型上限。
区分是真耗尽还是自增值虚高
如果 MAX(id) 远小于理论上限（比如才 50 万），但 AUTO_INCREMENT 显示 1000 万，说明是“空洞+虚高”，不是真耗尽。这种情况下可安全重置指针；但如果 MAX(id) 已达 2147483647 或 4294967295，就只能升级类型。
- 查虚高：运行
SHOW TABLE STATUS LIKE 'your_table';，对比输出中的Auto_increment和上一步的MAX(id) - 判断依据：只要
MAX(id) ，就存在可回收空洞；若两者几乎相等，且接近类型上限，就是硬性耗尽 - 特别注意：InnoDB 在事务回滚后仍会消耗自增值，所以即使没成功写入，ID 也已流失
紧急恢复时 ALTER TABLE AUTO_INCREMENT 的坑
重置自增起始值看似简单，但填错数字会直接导致下一条 INSERT 报主键冲突。核心原则只有一条：AUTO_INCREMENT 设置的值必须严格大于当前 MAX(id)。
- 正确操作：
ALTER TABLE your_table AUTO_INCREMENT = N;，其中N = MAX(id) + 1 - 常见错误：设成
1或任意 ≤MAX(id)的数 → 下次插入必然撞现有记录 - 别信“自动校准”：MySQL 不校验你填的值是否合理，只在插入时检查是否重复
- 执行前务必停写或切只读，避免并发写入干扰计数器状态
升级到 BIGINT 的关键实操点
当确认是真耗尽（MAX(id) 接近上限），改 BIGINT 是唯一长期解法，但不能只跑一条 MODIFY 就完事。
- 必须显式补全约束：
ALTER TABLE your_table MODIFY COLUMN id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT FIRST;—— 漏掉UNSIGNED或NOT NULL会导致约束丢失 - 外键必须同步改：所有引用该字段的外键列，类型必须一致，否则
ADD FOREIGN KEY会失败 - 应用层要过一遍：ORM 映射、JSON 序列化（JS Number 精度上限是 2^53）、监控埋点字段长度，都得确认支持 64 位整数
- 大表慎用直接
MODIFY：500MB 以上建议走“加新列→分批 UPDATE → 删旧列”三步法，避免锁表太久
最易被忽略的是：改完类型后，AUTO_INCREMENT 值不会自动跳过原 INT 上限。比如原 id 最大是 4294967295，升级 BIGINT 后得手动执行 ALTER TABLE your_table AUTO_INCREMENT = 4294967296;，否则下次插入仍会卡在 4294967295。
