我在询问之前尝试过搜索这个，但我找到的每个结果都提到 GUID 是 PK，但这里的情况并非如此。
我有一个数据库，它使用 INT 作为所有表的 PK。但是，数据是通过 API 调用访问的，并且要求不在任何 API 中返回或使用 INT 值。因此，我想在包含 GUID 的表上有一个额外的列。
现在我的问题是，如果我索引 GUID 列，这将产生什么样的性能影响？是积极的还是消极的？请记住，GUID 不是 PK 或 FK。
我认为你走在正确的轨道上，但不要从我这里拿走它......
在 Kimberly Tripp 的一篇文章的评论部分，她回应了一条主张与你的立场相反的评论，她不同意并争论你提出的相同解决方案(具有聚集的 int/bigint 主键的非聚集索引 guid)。
赫尔曼：
如果 GUID 是要建模的实体的内部标识符(即由选择使用)，则毫无疑问，它应该是群集主键。原因是添加代理项标识键(int 或 bigint)并将 GUID 主键降级为具有索引/唯一约束的列需要维护 2 个索引，并且根据我的经验，速度会减慢 2 倍。
金伯利·特里普
嘿，赫尔曼——实际上，我不同意。对于使用非聚集索引的基于点的查询，不会增加大量成本高昂的 IO。而且，维护高度碎片化的非聚集索引比维护高度碎片化的聚集索引要便宜得多。此外，GUID 可能会使非聚集索引不必要地宽 - 使它们占用：更多的日志空间、更多的磁盘空间、更多的缓存以及增加插入和访问的时间(尤其是在较大的查询/联接中)。
因此，虽然您可能觉得任意/代理键没有用(因为您从不直接查询它)，但通过非聚集索引间接使用它可能非常有效。这里肯定有一个"这取决于"的元素，但如果你只有几个非聚集索引，那么它可能比负索引更有益，而且通常很重要。干杯，
kt ~ GUID 作为主键和/或群集键 - 金伯利 L. 特里普
这应该没问题。 当然，您有任何索引和任何列占用更多空间的正常影响。 因此，数据修改会慢一些。 使用 GUID 查找记录与整数的速度稍慢。 除非您具有非常高吞吐量的应用程序，否则这些可能不是重要的考虑因素。
一个关键点是不应聚集 GUID 列。 这一点非常重要，因为 GUID 是随机的，但主键是有序的。 如果将 GUID 用于聚集索引，则几乎每个插入都将在两个现有记录之间移动，这需要大量数据移动。 相比之下，标识列作为聚集索引始终插入到数据的末尾。
我猜你对 GUID 的参考已经讨论了这个问题。