在SQL Server中使用GUID的性能影响

Question

我在尝试之前尝试过搜索这个但是我发现每个结果都提到了GUID作为PK而不是这里的情况。

我有一个数据库，它使用INT作为所有表的PK。 但是，数据是通过API调用访问的，并且要求不在任何API中返回或使用INT值。 因此，我想在包含GUID的表上有一个额外的列。

现在我的问题是，如果我对GUID列进行索引会产生什么样的性能影响？ 它会是积极的还是消极的？ 请记住GUID不是PK或FK。

Answer 1

我认为你走在正确的轨道上，但不要把它从我身上带走......

在关于Kimberly Tripp的一篇文章的评论部分，她回应了一个主张与你的立场相反的评论，并且她不同意并且争论你提出的相同解决方案（使用集群int / bigint主键的非聚集索引guid）。

赫尔曼：

如果GUID是被建模的实体的内在标识符（即由选择使用），那么它应该是群集主键而没有问题。 原因是添加代理身份密钥（int或bigint）并将GUID主键降级为具有索引/唯一约束的列需要维护2个索引并且根据我的经验减慢2倍。

---

金伯利·特里普

嘿，赫尔曼 - 实际上，我不同意。 对于使用非聚集索引的基于点的查询，不会增加大量昂贵的 IO。 并且，非严重分散的非聚集索引的维护比严重分散的聚簇索引所需的维护要便宜得多。 此外，GUID可能会使您的非聚簇索引不必要地变宽 - 使它们占用：更多的日志空间，更多的磁盘空间，更多的缓存以及在插入和访问上添加时间（特别是在更大的查询/连接中）。

因此，虽然您可能不觉得任意/代理键是有用的（因为您从不直接查询它），但通过非聚簇索引间接使用它会非常有效。 这里肯定有一个“它依赖”的元素，但是如果你甚至只有几个非聚集索引，那么它可能比负面更有利，而且通常也是如此。

干杯，
kt~ GUIDs作为PRIMARY KEYs和/或聚类键 - Kimberly L. Tripp

Answer 2

这应该没问题。 当然，您可以获得任何索引和任何列占用更多空间的正常影响。 因此，数据修改会慢一些。 使用GUID定位记录与整数相比稍慢。 除非您有非常高的吞吐量应用程序，否则这些可能不是重要的考虑因素。

一个关键点是GUID列不应该是群集的。 这非常重要，因为GUID是随机的，但主键是有序的。 如果GUID用于聚簇索引，则几乎每个插入都将在两个现有记录之间进行，这需要大量数据移动。 相反，作为聚簇索引的标识列始终插入数据的末尾。

我猜你对GUID的引用已经讨论过这个问题。