堆和索引中的分配掃描

我試圖理解堆和 B 樹中的分配掃描之間的區別，性能方面。

假設我們有一個 Orders 表，在 OrderDate 列上定義了一個聚集索引。

如果我們這樣查詢： SELECT orderid, custid, empid, shipperid, orderdate, filler FROM dbo.Orders;

執行計劃將包括一個帶有“Ordered”屬性值為“False”的聚集索引掃描，它（如果我理解正確的話）為儲存引擎留下了兩個關於如何執行它的選項：

1. 使用索引順序掃描，從第一個葉子開始並按索引順序進行
2. 使用分配掃描，從第一個 IAM 開始並按文件順序進行

問題是：第二個選項和Orders表是堆的情況（因此儲存引擎只能使用分配掃描）有區別嗎？如果沒有，在表上創建索引是否有任何優勢，主要是在沒有排序的情況下進行查詢？

或者我只是把整個事情弄錯了，它不會那樣工作。

…在表上創建索引是否有任何優勢，主要是在沒有排序的情況下進行查詢？

如果您計劃通過利用索引涵蓋的欄位的謂詞進行過濾或連接。例如，如果您只想Orders在去年查看具有 10 年數據的表，並且您OrderDate在B-Tree 的相關分支來為您的查詢提供服務，而不是讀取整個表，這會導致堆。

但是，如果您的意圖始終是始終讀取表中的全部數據，並且永遠不會UPDATE或DELETE基於任何謂詞從表中讀取數據JOIN，那麼無論是在其上創建聚集索引還是不是。儘管這並不常見，但有人將這種案例用於臨時表以外的表。

雖然索引確實按照索引定義中指定的欄位對 B-Tree 資料結構中的數據進行排序，但這並不是它的唯一目的和好處。由於 B 樹的結構（具有分支的非線性樹，而不是像堆這樣的線性結構），您得到的O(log(n))搜尋時間是搜尋時間而不是n搜尋時間。因此，無論您的查詢是否使用ORDER BY子句，如果它需要在謂詞上搜尋特定值（JOIN, WHERE,HAVING子句），那麼 B-Tree 很可能是優化器搜尋的更快的資料結構。

引用自：https://dba.stackexchange.com/questions/306560