自增主键溢出时事务不回滚而直接报错，已分配ID不可回收；ERROR 1062是计数器卡死导致的伪冲突；需监控AUTO_INCREMENT元数据值而非MAX(id)，改INT为BIGINT须谨慎避免锁表。
自增主键溢出时事务不会回滚，而是直接报错失败，且已分配的 ID 无法回收。
ERROR 1062 报错本质是复用最大值，不是真冲突
当 AUTO_INCREMENT 达到字段上限（如 INT UNSIGNED 的 4294967295）后，InnoDB 不再递增，下一次插入会反复尝试用这个最大值作为新 ID。由于该值已存在，触发 ERROR 1062 (23000): Duplicate entry '4294967295' for key 'PRIMARY' —— 这不是业务逻辑冲突，而是计数器“卡死”后的副作用。
- 事务中执行
INSERT后报此错，事务自动终止，但不会回滚已成功提交的其他语句（如前面的UPDATE） -
INSERT IGNORE或ON DUPLICATE KEY UPDATE会静默失败，不报错也不插入，极易导致数据丢失却无感知 - 即使整个事务被
ROLLBACK，那个已被消耗掉的 ID 也不会退还，空洞永久存在
别依赖 MAX(id)，监控必须盯紧 AUTO_INCREMENT 值
MAX(id) 在事务回滚、批量删除、唯一键冲突后严重失真，不能反映真实剩余空间。真正决定“还剩几次插入”的是 AUTO_INCREMENT 元数据值。
- 查当前自增值：
SELECT AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'tbl_name'; - 查字段类型上限：结合
COLUMN_TYPE（如int(10) unsigned→ 上限 4294967295）动态计算使用率 - 告警阈值设为 80%，90% 时已无缓冲时间；脚本建议每小时扫描一次，通过钉钉/邮件推送
ALTER TABLE MODIFY COLUMN 不是热操作，锁表风险极高
把 INT 改成 BIGINT 看似一劳永逸，但 ALTER TABLE t MODIFY id BIGINT UNSIGNED AUTO_INCREMENT 在大表上大概率触发全表拷贝，锁写入数小时。
- 必须提前确认磁盘空间：临时表需等量空闲空间
- 外键约束必须先
DROP FOREIGN KEY，改完再重建，否则报ERROR 1832 - MySQL 5.7+ 的
ALGORITHM=INPLACE对类型变更支持有限，实测仍可能降级为 copy - 更稳妥的三步法：
ADD COLUMN id_new→ 分批UPDATE→DROP COLUMN id+CHANGE id_new id，全程需停写或切低峰期
最易被忽略的点：8.0+ 虽持久化自增值，但手动 INSERT 指定大 ID 仍会推高 AUTO_INCREMENT
MySQL 8.0 将 AUTO_INCREMENT 值写入 redo log 和数据字典，崩溃后不丢失。但如果你在业务中偶尔 INSERT INTO t (id, name) VALUES (9999999999, 'x')，InnoDB 会把 AUTO_INCREMENT 值设为 MAX(当前值, 指定ID + 1) —— 这种“跳号式推进”会让监控误判，实际离上限比看起来更近。
