数据库设计：为什么使用自动增量字段作为主键？答案

【问题标题】：Database design: why use an autoincremental field as primary key?数据库设计：为什么使用自动增量字段作为主键？
【发布时间】：2010-01-14 00:18:56
【问题描述】：

这是我的问题：为什么我应该使用自动增量字段作为表上的主键而不是 UUID 值之类的东西？

一个比另一个的主要优势是什么？他们的问题和优势是什么？

【问题讨论】：

重复stackoverflow.com/questions/230351/…
@OrbMan 问题不同，这里没有重复。

标签： sql database-design database

【解决方案1】：

简单的数字占用更少的空间。每个 UUID 值占用 128 位。使用数字也更简单。对于大多数实际用途，32 位或 64 位整数可以很好地用作主键。 2⁶⁴ 是一个非常大的数字。

消耗更少的空间不仅可以节省硬盘空间，还意味着更快的备份、更好的连接性能，以及在数据库服务器内存中缓存更多真实内容。

【讨论】：

【解决方案2】：

您不必使用自动递增的主键，但我会这样做。原因如下。

首先，如果您使用的是 int，它们会比 UUID 小。

其次，使用整数进行查询比使用 UUID 更容易，尤其是当您的主键在其他表中作为外键出现时。

另外，请考虑您将在任何数据访问层中编写的代码。我的许多构造函数都将单个 id 作为 int。它很干净，并且使用像 C# 这样的类型安全语言 - 任何问题都会在编译时发现。

自动增量器的缺点？可能空间不足。我现在有一个 id 字段为 200M 的表。如果我照原样离开，它会在一年内突破 20 亿的上限。

您也可以争辩说自动递增的 id 没有内在意义，但 UUID 也是如此。

【讨论】：

@Paul - 同意你所说的一切。并且，当你接近 2B 时，你可以将数据类型更改为 BigInt。
@Randy 幸运的是，有问题的表包含每天都会重置的瞬态值，所以我打算每周做一份不错的工作，重新设定身份字段。

【解决方案3】：

我猜你所说的 UUID 是指 GUID？当您稍后必须合并表时，GUID 会更好。例如，如果您的本地数据库分布在世界各地，它们每个都可以为行标识符生成唯一的 GUID。稍后数据可以合并到一个数据库中，并且 id 不应该冲突。在这种情况下使用自动增量，您必须拥有一个复合键，其中另一半键标识原始位置，或者您必须在将数据导入主数据库时修改 ID。

【讨论】：

这是一个很好的观点 pro GUID - 但只需确保在 SQL Server 中使用 GUID 作为主键，但不作为集群键。