否定键是做什么用的？

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

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

至于为什么在表中使用“否定键”会有所帮助，这与“为什么在表中使用键有帮助”是同一个问题。键的“值”对其作为键的状态没有影响。一把钥匙，一把钥匙，一把钥匙。

重要的是密钥是否有效。

至于为什么允许使用负数的键是有用的，我可以提出一些理由：

如果您想将销售系统中的退货指示为负销售订单号，与正销售订单号匹配，从而使关联变得容易（这是幼稚的，设计不佳，但它可以在“电子表格”的意义上工作）。

如果您想要一个用户表，并指出带有负数的表是系统控制的（对于聊天提要用户，这正是这样做的）。

我可以继续说下去，但实际上负数之所以重要的唯一原因是你或我是否重视它。除此之外，密钥的价值与密钥本身没有任何关系。

如果我们在关于标识或自动编号列，值本身应该没有意义。（有时确实如此，根据 drachenstern 提到的 SO 的聊天用户，这是我自己之前做过的）

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

另一个例子：在小型复制场景中，对一个站点使用负值而对另一个站点使用正值可以隐含地了解任何给定行的来源。

并非所有数据库系统都支持无符号整数类型，MSSQL 就是其中之一。在这些情况下，整数键字段中可能存在负值，因为它们可能存在于类型中（您可以使用规则或触发器来阻止它们，如本示例所示，但可能不需要添加强制执行此类规则的开销每个中间件/更新）。

就数据库而言，主键的实际值并不重要，只要它在表中是唯一的即可。对它来说，-42 和 42 只是两个不同的数字，就像 42 和 69 一样 - 含义只会被你的代码赋予负值或非值。

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