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