MySQL自增ID溢出时报ERROR 1062，误判为重复主键；默认严格模式下报错，非严格模式可能静默截断；换BIGINT需同步外键和ORM适配，ALTER操作须分步并备份；应提前监控ID使用率并优化插入逻辑。
MySQL 自增 ID 溢出时到底报什么错
当 AUTO_INCREMENT 列达到其数据类型上限（比如 INT UNSIGNED 最大值 4294967295），下一次插入不会静默失败，而是直接报错：ERROR 1062 (23000): Duplicate entry '4294967295' for key 'PRIMARY'。这不是“主键冲突”的逻辑错误，而是溢出后 MySQL 尝试把 ID 回绕成 0 或负数（取决于有无 UNSIGNED），再与已有记录撞上导致的误判。
关键点在于：MySQL 不会主动拒绝插入，也不会自动扩容类型；它只是按类型规则做算术运算，结果超出范围后行为由 SQL mode 决定——默认 STRICT_TRANS_TABLES 下会报错，否则可能静默截断（极其危险）。
INT vs BIGINT：不只是“多几位”那么简单
从 INT UNSIGNED（约 42 亿）换到 BIGINT UNSIGNED（约 1.8 × 10¹⁹），看似只是改个类型，但实际影响几个关键维度：
-
BIGINT占用 8 字节，比INT（4 字节）多一倍空间，索引体积变大，内存和磁盘开销上升，尤其在宽表或高频查询场景下不可忽略 - 如果主键是
BIGINT，且被其他表用作外键，所有关联字段也得同步改成BIGINT，否则建约束会失败 - 某些旧版 ORM（如早期 Django 1.x、Laravel 5.x）默认把整型主键映射为 PHP/Python 的 32 位整数，
BIGINT值可能被截断或转成浮点，引发精度丢失
ALTER TABLE 修改自增列类型的安全操作步骤
直接 ALTER TABLE t MODIFY id BIGINT UNSIGNED AUTO_INCREMENT 在大表上可能锁表很久，且存在风险。稳妥做法分三步：
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 先确认当前最大 ID：
SELECT MAX(id) FROM t;，确保新类型能容纳（比如当前是 42 亿，BIGINT没问题，但INT SIGNED就不行） - 添加临时列并同步数据：
ALTER TABLE t ADD COLUMN id_new BIGINT UNSIGNED;，再用UPDATE t SET id_new = id;（建议分批，避免长事务） - 删原列、重命名、加自增：
ALTER TABLE t DROP COLUMN id, CHANGE id_new id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY FIRST;。注意：必须带PRIMARY KEY，否则AUTO_INCREMENT无效
过程中务必关闭写入或切到低峰期，且提前备份。别信“在线 DDL”能完全避免锁——ALGORITHM=INPLACE 对修改列类型支持有限，5.7+ 才较稳定。
比换类型更早该做的事：监控与预警
等 ID 快用完才行动已经晚了。真正有效的预防是建立监控：
- 定期查剩余空间：
SELECT TABLE_NAME, AUTO_INCREMENT, DATA_TYPE, CAST(COLUMN_TYPE AS CHAR) FROM information_schema.COLUMNS JOIN information_schema.TABLES USING (TABLE_SCHEMA, TABLE_NAME) WHERE TABLE_SCHEMA = 'your_db' AND EXTRA LIKE '%auto_increment%' AND DATA_TYPE IN ('tinyint','smallint','mediumint','int','bigint'); - 算使用率：对
INT UNSIGNED，若AUTO_INCREMENT / 4294967295 > 0.8就该预警 - 业务层埋点：在关键插入逻辑里加日志，记录 ID 接近阈值时的堆栈，定位哪些功能在疯狂产 ID（比如日志表没分区、消息表没归档）
最常被忽略的是：ID 耗尽往往不是因为数据量大，而是因为频繁的事务回滚、批量插入失败、或者误用 REPLACE INTO 导致自增跳号。查 innodb_autoinc_lock_mode 配置和应用层的插入模式，比单纯扩类型更能治本。
