sql - 数据库中 ID 字段的 INT 与唯一标识符

Question

我正在使用 SQL Server 2005(不久的将来可能会使用 SQL Server 2008)为网站创建一个新数据库。作为应用程序开发人员，我见过许多数据库使用 integer(或 bigint 等)作为用于关系的表的 ID 字段。但最近我还看到一些数据库在 ID 字段中使用唯一标识符 (GUID)。

我的问题是一个是否比另一个有优势？ integer 字段对于查询和连接等会更快吗？

更新:明确地说，这是表中的主键。

Answer 1

由于高随机性，GUID 作为聚集键存在问题。 Paul Randal 在上一期 Technet 杂志问答专栏中解决了此问题:I'd like to use a GUID as the clustered index key, but the others are arguing that it can lead to performance issues with indexes. Is this true and, if so, can you explain why?

现在请记住，我们的讨论专门针对聚集索引。您说您想使用该列作为“ID”，但不清楚您是将其作为聚集键还是仅作为主键。通常，两者重叠，因此我假设您想将其用作聚集索引。我上面提到的文章的链接解释了为什么这是一个糟糕的选择。

对于非聚集索引，GUID 仍然存在一些问题，但不像它们是表的最左侧聚集键时那么大。同样，GUID 的随机性会引入页面拆分和碎片，无论是在非聚集索引级别(问题要小得多)。

围绕 GUID 的使用有许多都市传说，这些传说根据 GUID 的大小(16 字节)与 int(4 字节)相比进行谴责，并 promise 如果使用它们，性能会受到可怕的打击。这有点夸张了。在正确设计的数据模型上，大小为 16 的 key 仍然可以是非常高性能的 key 。虽然确实是 int 的 4 倍大会导致索引中出现更多低密度非叶页，但对于绝大多数表来说，这并不是一个真正值得关注的问题。 B 树结构是一种自然良好的平衡树，并且树遍历的深度很少成为问题，因此基于 GUID 键而不是 INT 键来查找值在性能上是相似的。叶页遍历(即表扫描)不会查看非叶页，并且 GUID 大小对页大小的影响通常非常小，因为记录本身明显大于引入的额外 12 字节通过 GUID。因此，我对基于“是 16 字节与 4 字节”的传闻建议持保留态度。根据具体情况进行分析，并确定大小影响是否会产生真正的差异:表中有多少其他列(即 GUID 大小对叶页的影响有多大)以及有多少列引用正在使用它(即，有多少其他表会因为需要存储更大的外键而增加)。

我在对 GUID 进行临时辩护时指出了所有这些细节，因为它们最近受到了很多负面报道，其中一些是不值得的。它们有其优点，并且在任何分布式系统中都是不可或缺的(当您谈论数据移动时，无论是通过复制还是同步框架或其他方式)。我见过由于 GUID 的不良声誉而做出的错误决定，而这些决定是在没有经过适当考虑的情况下被回避的。但确实如此，如果您必须使用 GUID 作为聚集键，请确保解决随机性问题:尽可能使用顺序 guid。

最后，回答您的问题:如果您没有使用 GUID 的具体理由，请使用 INT。