聚集索引是否比包含包含的非聚集索引更快？

Question

我有一个包含 a、b、c、d、e、f、g 列的表，其中大约有 500,000 行。

有一个经常运行的查询会执行 SELECT * FROM table WHERE a = @a AND b = @b AND c = @c 。

是在 a、b 和 c 上创建一个 clustered index non-clustered index INCLUDE (d, e, f, g) 。

自发出 select * 以来，不确定包含是否有助于加快查询速度。

任何帮助，将不胜感激！

原文由 Mark Kadlec 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

对于 SELECT 来说，聚集索引是 最快 的，但它可能不一定是 正确的 选择。

聚集索引决定了记录的物理存储顺序（这就是每个表只能有一个的原因）。因此，虽然它对于 THAT 查询来说是最快的，但它可能会减慢其他查询的速度，并且如果其中一列发生更改，它可能会 KILL 更新和插入，这可能意味着需要物理重新定位记录。

如果更新了这些字段（包括包含的字段）中的任何一个，则 INCLUDE 也会以额外的存储和额外的索引维护为代价来加速该查询。

我会从 a、b 和 c 上的非聚集索引开始，看看这是否能让你的表现达到合理的水平。更多的可能只是用一个领域的速度来换取另一个领域的缓慢。

原文由 D Stanley 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 2

聚集索引会更快。

使用 SELECT * ，您的集群和非集群（包含全部）都包含每个页面中的所有列。但是，非聚集索引也包含对聚集键的引用——如果您向表中添加更多列，这是必需的，但实际上也是因为所有索引（索引视图除外）都是指向数据页的指针。 NCI 不会包含新列（固定 包含 列表），但数据页会。

SQL Server 可能 足够聪明，可以发现 SELECT * 可以通过 NCI（+includes）上的 INDEX SCAN 完成，而无需通过书签查找回数据页，但即便如此，该索引扫描也将是比等效的聚集索引扫描宽一列。

拥有 3 列聚类键通常不是一个好主意。您可以考虑使用简单的单列标识集群键的替代方法，并创建围绕 3 列集群的索引视图。

原文由 RichardTheKiwi 发布，翻译遵循 CC BY-SA 3.0 许可协议