身份列作为主键答案

【问题标题】：Identity Column as Primary Key身份列作为主键
【发布时间】：2009-12-03 07:08:08
【问题描述】：

如果将标识列作为主键是一种好的做法，您能否提出意见？对于 ORM 工具，在表上有标识列会有所帮助。但还有其他副作用，例如意外重复插入。

谢谢奈恩

【问题讨论】：

【解决方案1】：

是的，对于 SQL Server，使用 INT（或 BIGINT）IDENTITY 是非常好的做法。

SQL Server 使用主键作为其默认的集群键，集群键应始终具有以下属性：

INT IDENTITY 完全符合要求！

有关更多背景信息，尤其是为什么将 GUID 作为您的主要（因此是集群键）是一个坏的想法的一些信息，请参阅 Kimberly Tripp 的优秀帖子：

如果您有理由使用 GUID 作为主键（例如复制），那么一定要确保将 INT IDENTITY 作为您在这些表上的集群键！

马克

【讨论】：

【解决方案2】：

在没有复制或大量数据合并的环境中，IDENTITY 密钥对于服务器端生成的密钥是一种很好的做法。它们的实现方式不允许在同一个表中重复，所以不用担心。它们还具有最大程度地减少没有大量 DELETE 的表中的碎片的优势。

GUID 是常用的替代方法。它们的优点是您可以在 Web 层创建它们，而无需数据库往返。但是，它们比 IDENTITIES 大，并且可能导致极端的表碎片。由于它们是（半）随机的，因此插入分布在整个表格中，而不是集中在最后的一页中。

【讨论】：

要解决 GUID 碎片问题，请使用 COMB 样式的 GUID，而不是标准的完全随机的 GUID。在 MSSQL 上，有一个半 COMB 实现有时“足够好”，但不能保证在服务器重新启动时插入页尾。在大多数情况下，int 或 bigint 与 GUID（128 位）之间的空间差异并不值得担心。
除了在服务器重新启动时不保持顺序（如果很长时间），NEWSEQUENTIALID 功能也不能防止碎片或页面拆分；它只是将其定位在一个区域，直到值重置。另外，NEWSEQUENTIALID 只能作为列默认，所以只能在服务器上生成。此外，以这种方式生成的 GUID 比“纯”GUID 更容易猜测 - 因此使用 GUID 优于 IDENTITY 的三个好处不适用于 NEWSEQUENTIALID。

【解决方案3】：

我使用 Guid 是因为它在处理分布式应用程序时真的很有帮助。特别是当所有分布式实例也需要创建新数据时。

不过，在简单的情况下，我认为自动增量整数主键没有任何问题。实际上我更喜欢它们，因为它更容易直接使用 SQL 查询，因为它更容易记住。

【讨论】：