MySQL自增主键ID用完了怎么破

MySQL中的自增列

MySQL的自增列是一种非常常见的设置数据表类型，特别是设置表主键的时候，通常为了方便会将表主键ID设为自增，而自增列的类型通常与整数INT或BIGINT一起使用，这样写会不会有隐藏问题呢？肯定是有的，下面列举出需要注意的坑：

频繁手动插入或修改自增列值

• 隐藏风险：由于自增列大多为会作为主键列，手动插入或者修改子增值可能会导致数据重复，或者直接损坏主键唯一性约束。

• 最佳实践：避免对自增列手动操作修改，直接让数据库自己管理自增列值。

自增列值用完了怎么办

• 直接风险：自增列值用完了会导致后续数据直接无法插入，例如INT类型最大值 2,147,483,647，则此表最多插入次数据量值。

• 最佳实践：设计表时候避免使用INT，直接使用BIGINT（此数量已经符合大多数业务需要），同时平时多注意监控查看自增列的值，达到最大值之前做出应对措施。

• 其他策略：还可以考虑使用其他字段类型作为主键，例如UUID等。

自增列的顺序无法保证

• 原因： 正常情况下自增列的顺序是递增的，但不可避免的会出现人为操作数据库（，删除，复制，备份恢复等），从而导致自增列的不连续性。

• 最佳实践：避免用自增列的顺序性和连续性作为业务数据处理，此外也不用自增列作为表数据关系的基础。

自增列的恢复和备份

• 潜在风险：数据库备份和恢复时候都会要求保持原有数据的顺序，而如果有人为的操作或者非正常备份与恢复就会打乱原有列的顺序和连续性。

• 最佳实践： 在做自增列的备份与恢复确保没有人为的操作，备份与恢复期间表没有其他新增删除数据或者其他保证表数据顺序的方法。

---

自增列可能存在的其他问题

• 在分布式数据库环境中，使用自增列可能导致主键自增列冲突，需要中心化主键生成器

• 如果自增列为索引列，则在插入数据时MySQL会更新索引，影响数据库性能。

• 单点数据库自增列可能会成为性能瓶颈，特别在该并发场景中。

写在最后

MySQL在使用自增列时候需要特别注意，按照上述场景一一排查，降低潜在风险。关注程序员小徐，专注技术坑。