爲什麼/何時/如何選擇整個聚簇索引掃描而不是全表掃描？

Question

IMO，請指正...
聚集索引的葉含有真正的錶行，充滿聚集索引，與中間葉，含有比全表更多的數據（？）
爲什麼/時/如何是否在整個表掃描中選擇了整個聚簇索引掃描？

在SELECT查詢中使用的CUSTOMER_ID列上的聚簇索引如何不在SELECT列表或WHERE條件[1]中包含它？

更新：
我應該明白，全聚集掃描比全表掃描速度更快，因爲「每個數據頁包含指向下一個和以前的葉節點頁面，以便掃描並不需要使用更高級別的網頁在索引中「？
是否有任何其他原因像（非參與查詢）聚簇索引用於排序？

UPDATE2：
至於事後，連續訪問不能給的性能提升，同時通過IAM指針裝表可以並行。
聚集索引掃描是否意味着連續讀取頁面？
聚簇表是否意味着沒有IAM指針（無法進行全表掃描）？
爲什麼不能對全表進行全表掃描？
我還是不明白如何/爲什麼聚簇索引全掃描可以比全表掃描「更好」。
這是否意味着聚集索引可能導致性能惡化？

問題是關於聚簇表非堆（非索引）表。

UPDATE3：
是「全聚集索引掃描」真的同義詞「全表掃描」？
有什麼區別？

[1]索引覆蓋增強SQL Server查詢性能
http://www.devx.com/dbzone/Article/29530

Answer 1

請閱讀我的回答「沒有直接訪問聚集表中的數據行 - 爲什麼？」首先是。

「聚集索引的葉含有真正的錶行，充滿聚集索引，與中間葉，含有比全表更多的數據（？）」

見你混合了「表「與存儲結構。在你的問題的背景下，例如。考慮CI的大小而不是「表」，那麼你必須考慮CI減去葉級（這是數據行）。 CI，索引部分只是很小的。中間級別（如任何B-Tree）包含部分（不完整）鍵條目;它排除了最低級別，它是整個鍵入口，它位於該行本身，並且不被重複。

該表（完整配置項）可能爲10GB。 CI僅可能是10MB。有很多可以從10MB來確定，而不必去100GB。

理解：同一表（CI）上的等效NCI可能爲22MB;如果您刪除配置項，則同一個表上的等效NCI可能爲21.5MB（假設CI密鑰合理，不會變寬）。

「爲什麼/何時/如何在全表掃描中選擇整個聚簇索引掃描？」

很多時候。同樣的背景是，我們正在談論CI減葉水平。對於只使用CI中的列的查詢，CI中這些列的存在（實際上是任何索引）允許查詢爲「覆蓋查詢」，這意味着它可以通過索引完全服務，不需要去到數據行。思考部分按鍵的範圍掃描：BETWEEN x AND yY; x < = y;等

（總是存在這樣的優化器會選擇一個表掃描，有機會時你認爲它應該選擇索引掃描，BUŧ這是一個不同的故事。）

「我仍然不知道如何/爲什麼聚簇索引全掃描可以比全表掃描「更好」。「

（MS使用的術語比我在這裏的答案不太精確。）對於任何可以從10MB CI回答的查詢，我寧願在數據緩存中翻動10MB，而不是100GB。對於CI密鑰範圍內的相同查詢，這是10MB的一小部分。

對於需要「全表掃描」的查詢，是的，您必須閱讀CI的所有葉頁，即100GB。

Answer 2

聚集索引 - 或者更準確地說：它的葉子頁ARE表數據 - 這樣一個聚集索引掃描真的是一樣的作爲表掃描（對於具有聚集索引的表）。

如果你沒有聚簇索引，那麼你的表就是一堆 - 顯然，在這種情況下，如果你需要查看所有的數據，你不能做聚簇索引掃描，因爲沒有聚簇索引，所以你最終會得到一個表掃描，它只是觸及堆表的所有數據頁面。

Answer 3

聚簇索引的葉級是表。 「表掃描」是指沒有聚集索引的堆。

每個數據頁面都包含指向下一個和上一個葉節點頁面的指針，因此掃描不需要在索引中使用更高級別的頁面。