database - 应对数据库身份/自动编号最大化的策略

Question

自动编号字段（例如 SQL Server 中的“身份”）是为数据库表提供唯一键的常用方法。然而，鉴于它们很常见，在未来的某个时候，我们将处理它们将开始达到最大值的问题。

有谁知道或有推荐的策略来避免这种情况？我希望许多答案会建议切换到 guid，但考虑到这将需要大量的开发（尤其是在许多系统集成并共享价值的情况下），还有其他方法吗？我们是否正朝着新的硬件/操作系统/数据库将简单地允许整数值越来越大的方向前进？

Answer 1

如果您真的希望您的 ID 用完，请使用bigint. 对于大多数实际用途，它永远不会用完，如果用完了，您可能应该使用uniqueidentifier.

如果您每秒有30 亿bigint次（这意味着 3.0GHz 处理器上的一个事务/周期）事务，则需要大约一个世纪才能用完（即使您推迟了一点）。

也就是说，曾经，“ 640K 应该对任何人都足够了。 ”:)

Answer 2

请参阅以下相关问题：

• 重置主键（int 作为身份）
• bigint 对于事件日志表是否足够大？

接受/最高投票的答案几乎涵盖了它。

Answer 3

是否有可能循环浏览已从数据库中删除的号码？还是大多数记录还活着？只是一个想法。

我的另一个想法是 Mehrdad 建议改用 bigint

Answer 4

标识列通常设置为从 1 开始并以 +1 递增。负值与正值一样有效，因此可用标识​​符池加倍。

Answer 5

如果您可能会获得如此大的数据量，以至于您的 ID 达到最大值，您可能还希望支持复制，以便您可以拥有多个以某种方式同步的数据库实例。

对于这种情况，以及您希望避免使用“可猜测的”ID（Web 应用程序等）的情况，我建议使用 Guid（唯一标识符），默认使用新的 Guid 作为标识列的替代品。

由于 Guid 是唯一的，它们允许数据正确同步，即使记录是同时添加到系统中的。