如果我要通过 Guids 查询表（不管 Guids 的碎片问题），将 Guid 作为聚集索引而不是非聚集索引或根本没有索引会更快吗？
这个问题来自只读的角度。我只是好奇特定 Guid 的搜索行之间的速度是否会有所提高，并且在有/没有索引或有/没有聚集索引的情况下会更快地完成搜索吗？
或者，我对下一个问题的答案相当肯定，但现在将 int 标识符应用于上一个问题。如果该表由该 int 聚集，搜索会更快吗？（这是不是被表中的其他项目聚集在一起？）
我知道在这个主题上发布了许多其他问题，但我还没有在其中找到我正在寻找的具体答案：
Sequential Guid 主键列是否应该是聚集索引？
提高集群索引 GUID 主键的性能SQL Server uniqueidentifier
中唯一标识符 ID 列上的集群主键和索引我应该摆脱 Guid 列上的集群索引吗
谢谢你的帮助！
与 GUID 索引相比，使用整数聚集索引查询表肯定会更快。原因是数据类型的大小。
如果您已经决定使用 GUID 作为键，那么可能会使用 newSequentialId() 而不是 NewId() 生成这些 GUID，因为这将减少 Guid 索引中碎片的影响，因为 Id ae 总是在增加，并且您拥有的机会更少页面拆分。
补充一点，除非你有一个潜在的聚集索引候选者，即如果你使用这个 guid 不是为了关键目的，否则将它作为聚集索引是一个自然的选择。如果它是一个相对较小的表，那么当您可以选择不使用索引时，拥有索引总是好的。
假设 MS SQL Server。这可能适用于也可能不适用于其他 RDBMS：
如果您有一个聚集索引，那么它将是最快的，尽管如果您正在搜索单行，那么它与非聚集索引之间的差异将可以忽略不计。当您使用非聚集索引时，服务器需要首先在索引中找到正确的值，然后从表存储中获取完整记录。表存储是聚集索引，因此通过聚集索引进行搜索消除了该步骤（称为书签查找），但该步骤对于单行几乎是察觉不到的。
当聚集索引位于按范围选择的列上时（例如，事务日期并且您想要查找过去一个月的所有事务），聚集索引往往会为读取提供更大的优势。在这种情况下，服务器可以找到开始并在一次快速、连续的扫描中读取数据。
在 INT 上使用非聚集索引（所有其他条件相同）将比使用 GUID 稍快，因为索引本身会更小（因为 INT 比 GUID 小得多），这意味着服务器必须遍历更少的页面找到它想要获得的价值。在聚集索引的情况下，如果您的行大小与 GUID 和 INT 之间的差异相比已经很大，我认为您不会看到太大的差异，但我没有对此进行任何测试。
就像 Tom 已经提到的那样，在聚集索引上搜索单个元素总是会更快。这是因为聚集索引本身就是数据，在找到索引条目后不需要查找。
聚集索引的主要优点是能够提取数据的“范围”（如“上周”或“按日期排列的订单历史”）。由于 GUID 倾向于均匀分布在整个表中，因此您将无法在此处获得此好处。此外，每张表只能有一个聚集索引，因此请谨慎选择。
如果您最常查询特定范围的表，则将该表视为聚集索引。
还有第三种，称为覆盖指数。覆盖索引由几个字段组成，它们将能够满足最常见的查询。例如，您有一个带有 ID、Displayname、Password、LogonDate 的 USER 表，您将经常需要 DisplayName，基于 ID 创建索引，Displayname 将被视为查询的覆盖索引，例如
Select Displayname from USER where ID=XYZ
编辑：我忘了提一件事。当涉及到 SQL 时，GUID 是一个相当大的对象（嗯...... 16 字节）。将其作为聚集索引会强制该表上的所有其他索引包含指向 GUID 的 16 字节指针。如果您在该表上有一堆索引，这可以加起来。聚集索引最好是小而独特。这就是 INT 如此出色的原因。