主页 / dba / 问题 / 284254
Accepted
Dirk Boer
Asked: 2021-01-30 03:11:43 +0800 CST

由于 SQL Server 中没有 unsigned int，对于大型表来说，-2,147,483,648 的标识种子不是更有意义吗？

  • 772

我刚刚想到默认的身份种子是 1。我有一些表，我知道它们会在某个时候增长到数十亿。int.Min对于这些表，从 (-2,147,483,648)开始不是更有意义吗？

这可能会让您bigint在 4 年或 8 年内迁移您的密钥。可以足够相关。

这很常见吗？感觉很奇怪。有什么我想念的吗？

sql-server identity

2 个回答

  1. Best Answer

    就 SQL Server 而言，从 -2,147,483,648 开始没有任何问题。从 2,147,483,647 开始并向后计数IDENTITY(2147483647,-1)也是完全有效的。

    让我对这样做持谨慎态度的事情：

    1. 这可能会使那些不希望在这些职位上看到负值的人感到困惑。它很不寻常，很容易看起来像错误。如果没有别的，你可能会厌倦解释它。
    2. 如果您出于任何原因将 ID 传递给其他服务，它们可能无法通过输入验证，请不要期望看到否定的代码（外部系统不应该像这样关心您的内部 ID，但是有很多事情应该发生不！）。此外，应用程序其他层中的代码可能会使用 unsigned int32 使“从 int.max 向下”选项更加危险，因为直到低于 0 才会遇到问题。
    3. 人们有时会使用负魔数来表示特殊含义，这可能会导致冲突，从而导致难以解释的错误。例如，缩短WHERE (x.a<>y.a OR x.a IS NULL AND y.a IS NOT NULL OR x.a IS NOT NULL AND y.a IS NULL)到WHERE ISNULL(x.a,-1)<>ISNULL(x.a,-2)是我见过很多次的东西。您的 PK 不太可能，因为这永远不会NULL发生，但可能会在比较其他表中的 FK 值时发生。我什至见过有人使用somevalue>-1代替somevalue IS NOT NULL（显然有一种情况更有效，尽管他从未向我解释过这种情况可能是什么！）。数据库之外的代码中也可能存在这种和其他奇怪的恶作剧。
    4. 最重要的是：规模，特别是意想不到的规模。不会过早消亡的软件和数据往往比其创造者的愿景更长寿，并且随着时间的推移相应地增长得更多。除非您非常受存储或 RAM（可能在嵌入式系统中）的限制，否则请计划至少比您预期的高一个数量级。
      如果我预计在数据的生命周期中可能会达到约 400,000,000，远在考虑 2 或 4 000,000,000 之间的差异之前，我已经打算使用更大的键，因此通过使用负值加倍不会有太大的不同。
      您不想在四年内对 PK 之类的核心内容进行更改，但您更不想在八年内进行更改。在这两种情况下，如果设计持续那么久，您早就忘记了细节，并且许多其他小东西已经开始依赖于密钥，因此需要进行的更改会大量增加，即使是单张桌子也将是大量工作更改（除非大部分数据在一段时间后被删除），因为它包含那么多行，那么您也可以使用 FK 来处理所有引用它的行。
    • 19

  2. 不，你没有错过任何东西。身份是无意义的内部代理，仅供计算机分配和处理，计算机不关心您使用的是正数还是负数。

    然而..它从来没有那么简单。总会有人在某个地方试图阅读这些东西，理解它们并调和它们。我们只是发现考虑大量的负数比考虑大量的正数更难。不要让试图让你的系统正常工作的人变得更加困难。最终这些将泄漏到报告、外部参考、屏幕中。尝试告诉客户减去 20 亿，他们必须使用电话键盘输入客户 ID 才能访问他们的帐户！

    如果您认为在任何可能的将来都有可能溢出标识，请立即使用更大的数据类型。导致千年虫问题的考虑已经过去。磁盘便宜。每个查询使用的额外内存可以与知道应用程序设计为 50 年生命周期的安心相平衡。从现在开始分配最后一个整数的第 4 天（或第 8 天！），您不必实施额外的监控。

    我知道一个系统溢出并且标识减少了 21 亿，有效地从 int.Min 重新开始。我已经看到另一个使用负标识但失败了，因为记录将它们转换为 varchar(10) 截断减号。我知道另一个身份被定义为数字（18,0）的地方，只是为了确定。而且我看到另一个没有计划的溢出，导致系统停机一段时间。因为当您确实达到 int.max 时，根据定义，您有 40 亿行需要处理，而这并不能成为一个有趣的周末。

    • 9

相关问题