索引扫描总是索引扫描么？

问：使用NC扫描运算符，有方法知道索引是怎么扫描的么？

这个问题的一个答案是非聚集索引扫描总是扫描整个索引。

答：是的，总是100%。扫描运算符总是整个索引……

但是有一些特定的情况并不是这样。在这篇文章里我想专门讲下你总会碰到的一个特定案例——在你的查询里有TOP，MIN或者MAX表达式。

TOP，MIN，MAX

我们来看下面2个查询。 

SELECT TOP 10 * FROM Person.Person
GO

SELECT
    MIN(BusinessEntityID) AS 'Min',
    MAX(BusinessEntityID) AS 'Max'
FROM Person.Person
GO

第1个查询从Person .Person表返回前10行，第2个查询返回BusinessEntityID列的最小和最大值。当你看执行计划结果时，你会看到有趣的东西： 

第1个查询“扫描”聚集索引来获得前10行，对于第2个查询，聚集索引也被“扫描”2次来获得BusinessEntityID的最小值和最大值。但在这些情况里聚集索引扫描（Clustered Index Scan）并不是真正的聚集索引全扫描，因为TOP运算符缩短了聚集索引扫描（Clustered Index Scan）。这是什么意思呢？

一般来说，你知道你应该从右到左阅读执行计划，因为执行计划里的行也是从右流向左的。但在执行计划执行期间，是从左往右执行的。SQL Server内部使用所谓的迭代器模式（Iterator-Model），在那里执行计划里每个运算符从右边的运算符请求新的行。下图说明了这个非常重要的概念。

 

因为这个迭代器，最后的数据流是从右到左。现在当你看刚才生成的执行计划，你可以看到TOP运算符有所谓的TOP表达式（Top Expression）：

对于第1个查询TOP表达式是10，对于第2个执行计划里的2个TOP表达式是1。这个TOP表达式就定义TOP运算符消耗从右边的输入运算符的行数。当第1个查询里TOP运算符已消耗10行（前10行）后，TOP运算符就会缩短执行计划，且不会返回更多的行给SELECT运算符，这就意味着查询执行计划已经最终结束了。

同样的事情发生在第2个执行计划。为了获得BusinessEntityID的最小值（聚集键值），TOP运算符只消耗来自向前聚集索引扫描（Forward Clustered Index Scan）的第1行，最大值只消耗来自向后聚集索引扫描（Backward Clustered Index Scan）的第1行。

小结

当你在执行计划里看到TOP运算符，你总要想下这个特定场景：TOP运算符只会缩短你的扫描运算符。因此结论就是：在执行计划里，扫描并不总是扫描。

感谢关注！

参考文章：

https://www.sqlpassion.at/archive/2015/06/08/is-a-index-scan-always-a-index-scan/