Sql Server 2005索引視圖

Question

我在視圖上創建了一個唯一的聚集索引。聚集索引包含5列（該視圖中的30列），但使用此視圖的典型選擇將需要全部30列。

做一些測試表明查詢5列所花費的時間比所有30列快得多。這是因爲這是關於選擇6x列的天然開銷，或者是因爲索引視圖沒有將非索引列存儲在臨時表中，因此需要執行一些額外步驟來收集缺失列（連接我想呢？）

如果是後者，有什麼辦法可以防止這個？那麼，即使前者......有什麼辦法解決這個問題！

編輯：出於比較目的，只有5列的索引視圖上的選擇比基表上的相同查詢快大約10倍。但是，對所有列的選擇基本上與基本表上的查詢速度相同。

Answer 1

按照定義，聚集索引包含表中每一行中的每個字段。它基本上是對錶格的重新創建，但物理數據頁面按聚簇索引順序排列，使用B樹排序可快速訪問聚簇鍵的指定值。

你只是拉動值，或者你是否在其他25個字段獲得像MIN(), MAX(), AVG(), SUM()這樣的聚合函數？

Answer 2

索引視圖是數據的副本，可能（並且通常）以不同的方式存儲（聚集）到基表中。對於所有的目的

• 你現在有兩份數據
• SQL Server是足夠聰明地看到，視圖和表是查詢只涉及在列彼此
  • 別名索引視圖
  • 如果索引視圖包含所有列，它被認爲是一個完整的別名，可以使用（取代的）由任何地方查詢表
• 中優化當您只選擇從tbl 5列（其中有一個索引視圖ivw）
  • SQL服務器完全忽略你的表dexed視圖可以作爲只是一個指數的基表

  ，並只是給你從ivw

• 數據，因爲數據頁是短（只有5列），更多的記錄可以抓住到每個頁面檢索記憶，讓你在速度增加五倍

當您選擇全部30列時 - 索引視圖無法幫助您。該查詢完全忽略了該視圖，只是從基表中選擇數據。

IF選擇從所有30列中的數據，

• ，但是，從索引視圖的前4列的查詢過濾器，*
• 和過濾器是非常有選擇性的（將導致記錄的非常小的子集）

SQL Server可以使用索引視圖（掃描/搜索）快速生成一個小的結果集，它可以再使用JOIN回基表得到的休息數據。

• 然而，類似於常規索引，對（A，B，C，d，E）的索引或在這種情況下聚集在（A，B，C，d，E）索引視圖確實NOT幫助在（b，d，e）上搜索的查詢，因爲它們不是索引中的第一列。