自增id达到int上限后不会回绕，而是卡在最大值反复尝试插入导致主键冲突报错1062；根本解法是升级为bigint类型或采用分布式id方案。
因为自增计数器卡死在最大值，后续 INSERT 仍试图复用该值，触发主键唯一性冲突。
自增ID达到上限后不会溢出或回绕
MySQL 的 AUTO_INCREMENT 计数器是严格单调递增的，且受列数据类型约束。一旦达到 INT 有符号上限 2147483647（或无符号 4294967295），它就停在那里，不会自动归零、也不会跳到下一个可用值。
此时再执行 INSERT（不显式指定 id），InnoDB 会尝试分配下一个自增值——也就是再次使用 2147483647，而该值已存在，于是报错：
Error Code: 1062. Duplicate entry '2147483647' for key 'PRIMARY'
这不是“重复插入”，而是自增机制失效导致的逻辑冲突。
为什么有时报错是 1467 而不是 1062？
错误码取决于存储引擎行为和 MySQL 版本细节：
-
ERROR 1062：最常见，说明计数器还在“工作”，但生成的 ID 已存在； -
ERROR 1467 (HY000)：Failed to read auto-increment value from storage engine，多见于无符号INT达上限后，InnoDB 无法安全读取或推进计数器，直接放弃分配。
两者本质一致：自增能力已耗尽，不能再生成新 ID。
INT(50) 这种写法根本没用
很多人误以为 INT(50) 能扩大取值范围，其实括号里的数字只是显示宽度（仅影响 ZEROFILL 场景），对存储容量和最大值毫无影响。
真正决定上限的是类型本身：
-
INT→ 有符号上限2147483647； -
INT UNSIGNED→ 上限4294967295； -
BIGINT→ 有符号上限9223372036854775807，推荐用BIGINT UNSIGNED（上限18446744073709551615）。
建表时写成 id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY 才是防坑底线。
重置 AUTO_INCREMENT 值不能解决根本问题
执行 ALTER TABLE t AUTO_INCREMENT = N 看似能“续命”，但前提是 N 必须大于当前表中最大 id 值。如果最大 id 已是 2147483647，你设成 2147483648 会失败——MySQL 拒绝设置超出列类型范围的起始值。
更危险的是：有人用存储过程批量更新旧 id 来腾出空间，但这会破坏所有外键引用、索引顺序、业务逻辑中的 ID 依赖，线上慎用。
真正可靠的解法只有两个：改列类型为 BIGINT（需锁表），或提前设计分布式 ID 方案。后者虽重，但避免了未来某天凌晨三点被报警叫醒重跑 DDL。
