mysql自动递增主键耗尽

Question

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

Answer 1

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

Answer 2

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

Answer 3

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

还有其他的选择，如使用GUID，如果你真的担心用尽行，但我从来没有遇到过我实际上需要一个bigint的情况，我只是偶尔使用它们在volitle表格要安全。

Answer 4

这是通过设计，每百万个数据库都有一个类似这些主键的整数键。

如果删除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 5

用户niceguy07上传他的小猫的图片。图片保存为000.jpg，因为您使用主键作为文件名，而不是将不可信用户数据放入它们中（这是个好主意）。

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

niceguy07删除了他的小猫图片和用户fatperv08上传自己的图片只穿蝙蝠侠面具。

您的数据库重新使用主键，所以不幸现在与？picture_id = 12334的链接指向穿着蝙蝠侠面具的裸体胖perv的图片。

重新使用已删除记录的主键值是一个非常糟糕的主意。这是，事实上，一个bug，如果主键泄露出来的数据库，因为你在使用它：

• 一个URL
• 文件名
• 在一个文件中与其他数据一起倾倒
• 等

既然是，其实非常有用的做到以上的，不重用主键IDS是一个好主意 ...

Answer 6

数据库设计中的主键应该被视为所表示信息的唯一标识符。通过从表中删除一个ID，你基本上说这个记录应该不会再有。如果要取而代之的是你说唱片已经恢复了生机。现在在技术上，当你首先删除它时，你也应该删除所有外键引用。在这一点上，人们可能会试图说好，因为所有的痕迹都已经消失，没有理由不应该把它放在原处。那么，备份呢？假设您意外删除了记录，并且最终以其他方式取代了记录，您将无法轻松恢复该记录。这也可能会导致回滚问题。因此，不仅在数据库设计理论中重复使用ID不是必要的，而且是根本错误的。