否定键有什么用？

使用标准SQL数据库的某些新知识（当前大多数情况下是与MySQL配合使用）到目前为止，我还没有遇到过很多用法。

什么时候以及为什么使用负（或带符号）键索引表是有用的？

所有主键都是我们确定的值，它是记录中最重要的值。无论该键是有符号的int，无符号的int，字符串，blob（实际上是有限制的）还是UUID（或今天使用的任何名称），事实仍然表明它是键，并且它是最重要的事情。

由于我们不限于只使用正向数字作为键，因此考虑带符号的int只能达到约20亿，而无符号的int可以达到约40亿是有道理的。但是，使用带符号的int，将初始值设置为〜-20亿并设置增量为1并没有错。在达到约20亿条记录之后，您将达到“零”，然后您将继续达到约20亿。

至于为什么在表中包含“负键”会有所帮助，这与“为什么在表中包含键为什么有帮助”是同样的问题。密钥的“值”对其密钥状态没有影响。一键就是一键就是一键。

重要的是密钥是否有效。

至于为什么允许使用负数键会很有用，我可以提出一些原因：

如果要在销售系统中将退货指示为负销售订单号，该数字与正销售订单号相匹配，从而使关联变得容易（这很幼稚，设计欠佳，但在“电子表格”意义上有效）。

如果您想拥有一个用户表，并指出带有负数的表是系统控制的，那该怎么办（对于聊天供稿用户，这是可以做到的）。

我可以继续，但实际上负数之所以重要的唯一原因是您或我是否对其给予重视。除此之外，没有充分的理由使钥匙的价值与钥匙本身有关。

如果我们使用identity或autonumber列，则值本身应该没有任何意义。（有时会这样，根据drachenstern提到的SO的聊天用户，这是我自己做过的）

但是，如果使用带符号整数，通常会丢失一半的范围。
请参阅：表中的字段接近最大有符号或无符号32位整数时该怎么办？

另一个示例：在小型复制方案中，对于一个站点使用负值，对另一个站点使用正值，则可以隐含地了解任何给定行的源。

并非所有数据库系统甚至都支持无符号整数类型，MSSQL是不支持整数类型的一种。在这些情况下，整数键字段中可能出现负值，只是因为它们在类型中是可能的（如本例所示，您可以使用规则或触发器来阻止它们，但可能无需增加执行此类规则的开销。每次互动/更新）。

就数据库而言，主键的实际值并不重要，只要它在表中是唯一的即可。-42和42只是两个不同的数字，而42和69的含义相同-含义仅是代码的负数或负数。

不支持无符号整数类型可能是基于降低复杂度的设计决策-即，不希望两个不同的32位整数类型在分配它们之间的值时担心检查范围。它确实将自动递增字段中可能从0或1开始的索引数量限制为无符号类型（〜2e9而不是〜4e9）的索引数量的一半，但这很少是一个重大问题（如果您可能需要无论如何，您都可能会使用许多这样大小的键值，尤其是在使用64位体系结构的情况下，此类值的处理效率不低于32位值，尽管您可能需要完整范围并需要如果出于空间原因而坚持使用32位，则可以从-2,147,483,647开始递增。