問：使用NC掃描運算符，有方法知道索引是怎么掃描的么？

這個問題的一個答案是非聚集索引掃描總是掃描整個索引。

答：是的，總是100%。掃描運算符總是整個索引……

但是有一些特定的情況并不是這樣。在這篇文章里我想專門講下你總會碰到的一個特定案例——在你的查詢里有TOP，MIN或者MAX表達式。

TOP，MIN，MAX

我們來看下面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），在那里執行計劃里每個運算符從右邊的運算符請求新的行。下圖說明了這個非常重要的概念。

?

因為這個迭代器，最后的數據流是從右到左。現在當你看剛才生成的執行計劃，你可以看到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/

轉載于:https://www.cnblogs.com/woodytu/p/4746271.html

總結

以上是生活随笔為你收集整理的索引扫描总是索引扫描么？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。