当Guid是聚集索引时，Guid会更快地搜索表格吗？

Question

如果我要通过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

感谢您的帮助！

Answer 1

使用Integer聚簇索引时，表肯定会比GUID索引更快地查询。原因是数据类型的大小。

如果您已经决定使用GUID作为密钥，则可能使用newSequentialId（）而不是NewId（）生成这些GUID，因为这会降低Guid索引中碎片的影响，因为Ids总是在增加，并且您的机会较少有一个页面拆分。

除此之外，将此作为聚簇索引使用是很自然的选择，除非您有可能成为聚簇索引的候选者，即如果您使用此guid不是出于关键目的。如果它是一个相对较小的表，当你可以选择没有索引时，它总是很好的索引。

Answer 2

假设MS SQL Server。这可能适用于或不适用于其他RDBMS：

如果您有聚簇索引，那么它将是最快的，但如果您正在搜索单行，那么它与非聚集索引之间的差异将可以忽略不计。当您使用非聚集索引时，服务器需要首先在索引中找到正确的值，然后从表存储中获取完整记录。表存储是聚簇索引，因此通过聚簇索引进行搜索会消除该步骤（称为书签查找），但对于单行来说，该步骤几乎察觉不到。

当聚类索引位于按范围选择的列（例如，事务日期并且您希望查找过去一个月的所有事务）时，它们往往会为读取提供更大的优势。在这种情况下，服务器可以找到开始，只需一次快速连续扫描即可读取数据。

在INT上使用非聚集索引（所有其他条件相同）将比使用GUID稍快，因为索引本身会更小（因为INT比GUID小得多），这意味着服务器必须遍历较少的页面以找到它想要获得的值。在聚集索引的情况下，如果您的行大小已经比GUID和INT之间的差异大，我认为您不会看到太大差异，但我没有对此进行任何测试。

Answer 3

就像Tom已经提到的那样，对单个元素的聚簇索引的搜索总是会更快。这是因为聚簇索引本身就是数据，在找到索引条目后不需要查找。

聚集索引的主要优点是能够提取数据的“范围”（如“上周”或“按日期订购历史”）。由于GUID往往会在桌面上均匀分布，因此您无法在此处获得此优势。此外，每个表只能有一个聚簇索引，因此请仔细选择。

如果您最常查询特定范围的表，请将其视为聚簇索引。

还有第三种，称为覆盖指数。覆盖索引由几个字段组成，这些字段能够满足最常见的查询。例如，你有一个带有ID，Displayname，Password，LogonDate .....的USER表，你需要经常使用DisplayName，根据ID创建一个索引，Displayname将被视为一个覆盖索引，如< / p>

Select Displayname from USER where ID=XYZ

编辑： 我忘了提一件事。对于SQL（嗯...... 16字节），GUID是一个非常大的对象。将它作为聚簇索引强制该表上的所有其他索引包含指向GUID的16字节指针。如果你在该表上有一堆索引，这可以加起来。聚集索引最好是它小而且独特。这就是为什么INT非常好。