7

我有一个表定期暴露于大型插入和删除（因此在主 id 列的数字序列中有很大的差距）。它有一个“int”类型的主 id 列，该列已更改为“bigint”。尽管发生了这种变化，这种数据类型的限制也将不可避免地在未来的某个时候被超过（目前的使用情况表明明年左右会出现这种情况）。

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

我们的自动增量 ID 已经接近 5 亿大关。该表将与文件数据关联的关键字保存在单独的表中。每个文件数据行在关键字表中可能有多达 30 个与之关联的关键字，因此在您不断插入和删除数以万计的文件之后，它们才真正开始堆积起来。目前，关键字表包含关键字和与之关联的文件的 id，所以如果我去掉当前的主 id 列，除了关键字 (varchar) 和文件 id (int) 字段组合之外，将没有唯一标识符，这将是一个糟糕的主键。

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

4

4 回答 4

28

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

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

于 2013-06-05T09:47:24.617 回答
10

如果您不需要该列，因为您有另一个唯一的记录标识符。就像提供的 measure_id 或其他任何内容，甚至是组合键：measurement_id + location_id 一样，不需要使用自动增量键。如果有任何机会，您将不会拥有唯一的密钥，而不是确定一个。

如果我需要一个非常大的自动增量 ID 怎么办？

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

于 2012-07-21T10:08:40.930 回答
7

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

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

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

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

如果我们每秒向表中插入 10 亿条记录，则需要 292 年

所以不用担心

于 2016-12-28T00:33:53.367 回答
0

也许为时已晚，但您可以在 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。EX 如果你有 800 行并删除了 ID 200-400，下次你写新行时 ID 仍然计数为 801

于 2017-03-06T01:50:16.130 回答