mysql自动增量主键耗尽

Question

我维护一个带有ID AUTO INCREMENT PRIMARY KEY的表。当我删除一个条目并重新添加一个条目时，新条目不会获取前一个条目的ID，而是再次增加一个条目。这是正常的，是否建议不要改变这种行为？我只是觉得这是在创建一个不可扩展的系统，因为它最终会耗尽索引。

Answer 1

这是设计的，数以百万计的数据库具有像这样的主键和整数键。

如果您删除了90％的插入内容，那么在4亿行^{之后将会用完密钥1）}
如果你这样做，你可以做一个

ALTER TABLE `test`.`table1` MODIFY COLUMN `item_id` BIGINT UNSIGNED NOT NULL
, ROW_FORMAT = DYNAMIC;

列item_id将成为您的主键。
之后，您再也不用担心会耗尽密钥空间。

不要试图用bigint主键开始！

1. 它会使您的所有查询变慢。
2. 它会使表更大。
3. 在InnoDB上，每个辅助索引都包含主键，插入时可以更快地使用 小主键。
4. 对于大多数桌子，你永远不需要它。

如果你知道你的大表将有比整数可以容纳更多的行，那么一定要把它变成一个bigint，但是你应该只对真正需要它的表执行此操作。特别是在InnoDB表上。

不要使用GUID，它只是浪费了很多空间，99.99％的时间无缘无故地放慢速度。

---

^1）使用无符号！整数作为主键。

Answer 2

用户niceguy07上传了他的小猫的照片。图片保存为000012334.jpg，因为您使用主键作为文件名，而不是将不受信任的用户数据放入其中（这是一个好主意）。

niceguy07发送一个带有？picture_id = 12334的链接到他的约会。

niceguy07删除了他的小猫照片，用户fatperv08上传了一张自己只戴着蝙蝠侠面具的照片。

您的数据库重新使用主键，所以现在很难与？picture_id = 12334的链接指向一张戴着蝙蝠侠面具的赤裸胖子的照片。

重新使用已删除记录的主键值是一个非常糟糕的主意。事实上，这是一个错误，如果主键在数据库中泄漏，因为你在以下地方使用它：

• 一个网址
• 文件名
• 与文件中的其他数据一起转储
• 等

因为事实上，完成上述所有操作非常有用，不重复使用主键ID是个好主意 ......

Answer 3

没关系。根据您期望的记录数量，您可能需要确保它是bigint类型，但在大多数情况下int应该没问题。

Answer 4

这很正常。不要担心ID是顺序的。

Answer 5

这取决于您计划拥有的记录数量以及删除和添加的记录数量，但如果这是一个问题，请使用bigint主键。

还有其他选项，例如使用GUID，如果你真的担心用完行，但我从来没有遇到过我实际需要bigint的情况，我偶尔会使用他们在volitle表上是安全的。

Answer 6

数据库设计中的主键应被视为所表示信息的唯一标识符。通过从表中删除ID，您实际上是说该记录不再存在。如果有什么东西可以取而代之，那么你就是说记录已经恢复了生机。从技术上讲，当你首先删除它时，你应该删除所有外键引用。在这一点上，人们可能很想说清楚，因为所有的痕迹都消失了，而没有理由不应该取而代之。那么，备份怎么样？假设您意外删除了记录，最终被其他内容取代，您将无法轻松恢复该记录。这也可能导致回滚问题。因此，在数据库设计理论中不仅重用ID不是必要的，而且是根本错误的。