聚集索引的叶子包含实际的表行,所以带有中间叶子的完整聚簇索引包含的数据比完整的表(？)多得多
为什么/何时/如何在整个表扫描中选择整个聚簇索引扫描？
SELECT查询中使用的CUSTOMER_ID列上的聚簇索引如何在SELECT列表或WHERE条件[1]中不包含它？
更新：
我是否应该理解完整的群集扫描比全表扫描更快,因为“每个数据页都包含指向下一个和上一个叶节点页面的指针,因此扫描不需要使用索引中的更高级别的页面”？
有没有其他原因如(非参与查询)聚集索引用于排序？
UPDATE2：
由于事后的想法,连续访问不能提高性能,而通过IAM指针加载表可以并行化.
聚簇索引扫描是否意味着连续页面读取？
集群表是否意味着没有IAM指针(全表扫描不可能)？
为什么群集表不能被全表扫描？
我仍然不明白为什么/为什么聚簇索引全扫描可以比全表扫描“更好”.
这是否意味着拥有聚集索引会导致性能恶化？
问题是关于聚簇表而不是堆(非索引)表.
UPDATE3：
“完全聚集索引扫描”真的是“全表扫描”的同义词吗？
有什么区别？
[1]索引覆盖提升sql Server查询性能
http://www.devx.com/dbzone/Article/29530
解决方法
“聚簇索引的叶子包含真实的表行,所以带有中间叶子的完整聚簇索引包含比完整表(？)更多的数据”
看到你正在混合“表”与存储结构.在您的问题的背景下,例如.考虑CI的大小而不是“表”,那么你必须考虑CI减去叶级(这是数据行).仅CI,索引部分很小.中间级别(如任何B树)包含部分(非完整)密钥条目;它排除了最低级别,即完整的键入口,它位于行本身,并且不重复.
表(完整CI)可能是10GB. CI仅为10MB.可以从10MB确定很多,而不必去100GB.
为了解：同一个表(CI)上的等效NCI可能是22MB;如果删除CI,则同一表上的等效NCI可能为21.5MB(假设CI密钥合理,不宽胖).
“为什么/何时/如何在全表扫描中选择整个聚簇索引扫描？”
经常.在上下文中,我们正在谈论CI-minus-Leaf水平.对于仅使用CI中的列的查询,CI中的那些列(实际上是任何索引)的存在允许查询成为“覆盖查询”,这意味着它可以完全从索引服务,无需去到数据行.思考部分键的范围扫描：BETWEEN x和yY; x< = y;等等 (当您认为应该选择索引扫描时,优化器总是有可能选择表扫描,这是一个不同的故事.) “我仍然不明白为什么/为什么聚集索引全扫描可以比全表扫描”更好“.” (MS使用的术语不如我在这里的答案精确.)对于任何可以从10MB CI回答的查询,我宁愿通过数据缓存流失10MB,而不是100GB.对于相同的查询,以CI键上的范围为界,这只是10MB的一小部分. 对于需要“全表扫描”的查询,是的,您必须阅读CI的所有Leaf页面,即100GB.
