自增ID用尽后报Duplicate entry错误而非数值溢出，是因为InnoDB检测到current_autoinc已达MAX_VALUE时跳过递增、复用最大值，导致主键重复；事务回滚不退还ID加剧耗尽风险，未设主键时row_id回绕还会静默覆盖数据。
自增ID用尽后为什么报 Duplicate entry 错误
不是数值溢出报错，而是主键唯一性冲突。MySQL检测到 AUTO_INCREMENT 值已达字段上限（如 INT UNSIGNED 的 4294967295）后，不再递增，后续所有插入都尝试复用这个最大值。一旦该值已存在于表中，就触发 ERROR 1062 (23000): Duplicate entry '4294967295' for key 'PRIMARY'。
为什么不是报整型溢出或越界错误
InnoDB 显式规避了整型回绕风险：源码逻辑中，当 current_autoinc == MAX_VALUE 时直接跳过递增步骤，不计算 MAX_VALUE + 1。这避免了有符号类型负数回卷、无符号类型归零等不可控行为，但代价是“卡死在最大值”。所以错误本质是业务层的主键重复，而非底层数据类型异常。
事务回滚会让耗尽来得更快
自增值一旦分配，即使事务 ROLLBACK 也不会退还。例如：
- 事务中执行
INSERT分配了 ID4294967295 - 随后
ROLLBACK，数据没写入，但AUTO_INCREMENT值已永久变为4294967295 - 下一次插入仍会尝试用
4294967295，立刻冲突
这种“只进不退”机制让耗尽比预估更早发生，尤其在高并发或频繁失败重试的场景里。
没设主键时 row_id 覆盖更隐蔽
若表未定义主键，InnoDB 用全局 dict_sys.row_id（6 字节，上限 2^48 - 1）生成隐式主键。达到上限后，row_id 加 1 取低 6 字节变成 0，新数据会覆盖已有 row_id = 0 的记录——不报错，但数据静默丢失。这种失效方式比主键冲突更难察觉。
真正危险的不是“用完”，而是用完前缺乏监控；AUTO_INCREMENT 值接近上限时，INSERT 已处于悬崖边缘，但没有任何预警信号。
