为什么/何时/如何选择整个聚集索引扫描而不是全表扫描？答案

【问题标题】：Why/when/how is whole clustered index scan chosen rather than full table scan?为什么/何时/如何选择整个聚集索引扫描而不是全表扫描？
【发布时间】：2011-04-27 14:13:21
【问题描述】：

IMO，请纠正我...
聚集索引的叶子包含真正的表行，因此带有中间叶子的完整聚集索引包含比完整表更多的数据（？）
为什么/何时/如何选择整个聚集索引扫描而不是全表扫描？

~~如何在 SELECT 查询中使用 CUSTOMER_ID 列上的聚簇索引，该索引在 SELECT 列表或 WHERE 条件 [1] 中都不包含它？~~

更新：
~~我应该明白全集群扫描比全表扫描快，因为“每个数据页都包含指向下一个和上一个叶节点页的指针，因此扫描不需要使用更高级别索引中的页面”？~~
是否有任何其他原因，例如（不参与查询）在排序中使用聚集索引？

更新 2：
事后考虑，连续访问无法提高性能，而通过 IAM 指针加载表可以并行化。
聚集索引扫描是否意味着连续的页面读取？
聚簇表是否意味着缺少 IAM 指针（不可能进行全表扫描）？
为什么聚簇表不能全表扫描？
我仍然不明白聚集索引全扫描如何/为什么比全表扫描“更好”。
这是否意味着拥有聚集索引会导致性能恶化？

问题是关于聚集表而不是堆（非索引）表。

更新3：
“全聚集索引扫描”真的是“全表扫描”的同义词吗？
有什么区别？

[1] 索引覆盖提升 SQL Server 查询性能
http://www.devx.com/dbzone/Article/29530

【问题讨论】：

聚集索引扫描不一定比表扫描快，但表扫描只发生在堆上（即没有聚集索引的表）。 “堆扫描”是表扫描的更准确名称，因为表是一种逻辑结构，而堆和索引是执行计划中使用的物理结构。

标签： sql-server database performance indexing clustered-index

【解决方案1】：

请先阅读我在“无法直接访问聚集表中的数据行 - 为什么？”下的答案。

“聚集索引的叶子包含真正的表行，因此带有中间叶子的完整聚集索引包含比完整表更多的数据（？）”

看到您将“表格”与存储结构混为一谈。在你的问题的背景下，例如。考虑 CI 的大小而不是“表”，那么您必须考虑 CI 减去叶级别（即数据行）。 CI，仅索引部分，很小。中间层（像任何 B-Tree 一样）包含部分（非完整）键条目；它不包括最低级别，即完整的键条目，它位于行本身中，并且不重复。

表（完整 CI）可能为 10GB。 CI 可能只有 10MB。有很多东西可以从 10MB 确定，而不必转到 100GB。

供理解：同一张表（CI）上的等效NCI可能是22MB；如果您删除 CI，同一张表上的等效 NCI 可能是 21.5MB（假设 CI 密钥是合理的，而不是太宽）。

“为什么/何时/如何选择整个聚集索引扫描而不是全表扫描？”

经常。同样的上下文是，我们正在谈论 CI-minus-Leaf 级别。对于仅使用 CI 中的列的查询，CI 中这些列（实际上是任何索引）的存在允许查询成为“覆盖查询”，这意味着它可以完全从索引中提供服务，无需去到数据行。考虑部分键的范围扫描：BETWEEN x AND yY； x

（当您认为它应该选择索引扫描时，优化器总是有可能选择表扫描，但那是另一回事。）

“我仍然不明白聚集索引全扫描如何/为什么比全表扫描“更好”。”

（MS 使用的术语不如我在这里的答案精确。）对于可以从 10MB CI 回答的任何查询，我宁愿通过数据缓存搅动 10MB，而不是 100GB。对于以 CI 键范围为界的相同查询，这只是 10MB 的一小部分。

对于需要“全表扫描”的查询，是的，您必须阅读 CI 的所有 Leaf 页面，即 100GB。

【讨论】：

【解决方案2】：

聚集索引的叶级是表。 “表扫描”是指没有聚集索引的堆。

每个数据页面都包含指向下一个和上一个叶节点页面的指针，因此扫描不需要使用索引中的更高级别页面。

【讨论】：

【解决方案3】：

聚集索引 - 或者更准确地说：它的叶页是表数据 - 所以聚集索引扫描实际上与表扫描相同（对于具有聚集索引的表）。

如果你没有聚集索引，那么你的表就是一个堆——显然，在这种情况下，如果你需要查看所有数据，你不能进行聚集索引扫描，因为没有聚集索引，所以你最终会得到一个表扫描，它只触及该堆表的所有数据页。

【讨论】：