mysql自动增量主键耗尽

Question

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

Answer 1

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

如果你删除了90%的插入,你将在4亿行之后用完钥匙¹⁾
如果你这样做,你可以做一个

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%的时间无缘无故地放慢速度.

¹⁾使用未签名!整数作为主键.

Answer 2

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

niceguy07发送链接到？picture_id = 12334到他的约会.

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

你的数据库重用主键,所以现在很难与？picture_id = 12334的链接指向一个戴着蝙蝠侠面具的裸体脂肪的图片.

重新使用已删除记录的主键值是一个非常糟糕的主意.事实上,这是一个错误,如果主键泄漏出数据库,因为您在以下位置使用它:

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

事实上,由于它实际上非常有用,所以不重复使用主键ID是一个好主意 ......

Answer 3

没关系.根据您期望的记录数量,您可能希望确保它是一种bigint类型,但int在大多数情况下应该没问题.