Question

我有一个表定期暴露于大型插入和删除（因此，主id列的数字序列中存在大的间隙）。它有一个'int'类型的主id列，它被改为'bigint'。尽管有这种变化，但在未来的某个时间点也将不可避免地超出此数据类型的限制（当前使用情况将表明在未来一年左右的情况）。

你如何处理这种情况？我想知道（震惊恐怖）我是否甚至需要主键列，因为它在任何查询中都没有以任何明显的方式使用或被其他表引用等等。删除列是一个解决方案吗？或者那种行为会让你厌恶地从mysql社区中被驱逐出去？！

对于自动增量ID，我们已经接近5亿大关。该表在单独的表中保存与文件数据相关联的关键字。每个文件数据行在关键字表中可以有多达30个与之关联的关键字，因此在您不断插入和删除数万个文件后，它们真正开始堆叠。目前，关键字表包含关键字及其关联的文件的ID，因此，如果我删除了当前的主要id列，除了关键字（varchar）和文件id（int）字段之外，没有唯一的标识符，这将是一个可怕的主键。

非常感谢所有的想法/答案/经验/解决方案。

Answer 1

我知道它已经在一年前得到解答，但只是继续关于Luc Franken的回答，

如果每秒插入5亿行，则需要大约1173年才能达到BIG INT的限制。所以是的，我认为不要担心

Answer 2

如果您不需要该列，因为您有另一个唯一的记录标识符。就像提供的measurement_id或任何甚至是组合键一样：measurement_id + location_id不需要使用自动增量键。如果有可能你没有唯一的钥匙而不是肯定的。

What if I need a very very big autoincrement ID?

你真的确定你有这么多插入和删除你会达到极限吗？

Answer 3

如果我们每秒将十万（100,000）条记录插入表中，则需要2,924,712次

如果我们每秒在表中插入100万（1,000,000）条记录，则需要292，471年

如果我们每秒插入1000万（10,000,000）条记录，则需要29，247年

如果我们每秒在表格中插入1亿条记录，则需要2，925年

如果我们每秒在表中插入1000万条记录，则需要292年

所以不要担心

Answer 4

也许有点太晚了，但你可以在DELETE中添加触发器，

这是SQL SERVER中的示例代码

CREATE TRIGGER resetidentity
    ON dbo.[table_name]
    FOR DELETE
AS
    DECLARE @MaxID INT
    SELECT @MaxID = ISNULL(MAX(ID),0)
    FROM dbo.[table_name]
    DBCC CHECKIDENT('table_name', RESEED, @MaxID)
GO

简而言之，这将重置您的ID（如果它是自动增量和主要）。例如：如果您有800行并删除了最后400行，则下次插入时，它将从401而不是801开始。

但是，如果您在中间记录中删除它，它将不会重新排列您的ID。如果您有800行并删除了ID 200-400，则在下次写入新行时ID仍然计为801 < / p>

主键ID达到bigint数据类型的限制

4 个答案: