这个问题的一个答案是非聚集索引扫描总是扫描整个索引。
我们来看下面2个查询。
1 SELECT TOP 10 * FROM Person.Person 2 GO 3 4 SELECT 5 MIN(BusinessEntityID) AS 'Min', 6 MAX(BusinessEntityID) AS 'Max' 7 FROM Person.Person 8 GO
第1个查询从Person .Person表返回前10行,第2个查询返回BusinessEntityID列的最小和最大值。当你看执行计划结果时,你会看到有趣的东西:
第1个查询“扫描”聚集索引来获得前10行,对于第2个查询,聚集索引也被“扫描”2次来获得BusinessEntityID的最小值和最大值。但在这些情况里聚集索引扫描(Clustered Index Scan)并不是真正的聚集索引全扫描,因为TOP运算符缩短了聚集索引扫描(Clustered Index Scan)。这是什么意思呢?
一般来说,你知道你应该从右到左阅读执行计划,因为执行计划里的行也是从右流向左的。但在执行计划执行期间,是从左往右执行的。SQL Server内部使用所谓的迭代器模式(Iterator-Model),在那里执行计划里每个运算符从右边的运算符请求新的行。下图说明了这个非常重要的概念。
对于第1个查询TOP表达式是10,对于第2个执行计划里的2个TOP表达式是1。这个TOP表达式就定义TOP运算符消耗从右边的输入运算符的行数。当第1个查询里TOP运算符已消耗10行(前10行)后,TOP运算符就会缩短执行计划,且不会返回更多的行给SELECT运算符,这就意味着查询执行计划已经最终结束了。
当你在执行计划里看到TOP运算符,你总要想下这个特定场景:TOP运算符只会缩短你的扫描运算符。因此结论就是:在执行计划里,扫描并不总是扫描。
感谢关注!