由于 SQL Server 中没有 unsigned int，因此 -2,147,483,648 的标识种子对大表是否更有意义？

Question

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

这可能只是bigint在 4 年或 8 年内将您的密钥迁移到不同。可以足够相关。

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

Answer 1

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

会让我警惕的事情：

1. 这可能会使那些不希望在这些职位上看到负值的人感到困惑。它很不寻常，很容易看起来像错误。如果不出意外，你可能会厌倦解释它。
2. 如果您出于任何原因将 ID 传递给其他服务，它们可能会导致输入验证失败，请对该代码执行不希望看到否定的操作（外部系统不应该像这样关心您的内部 ID，但是有很多事情应该发生'不是！）。此外，应用程序其他层中的代码可能会使用无符号 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 来处理所有引用它的数据。

Answer 2

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

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

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

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