用SQLServer2000索引檢視提高效能

摘要：本文件介紹 SQL Server 2000 企業版的新功能 - 索引檢視。講解索引檢視並討論一些提高效能的具體方案。

目錄

什麼是索引檢視？
透過索引檢視提高的效能
使用索引檢視的好處
查詢最佳化器如何使用索引檢視
設計的考慮因素
設計準則
使用“索引微調嚮導”
維護索引檢視
建立索引檢視
使用 SET 選項以獲得一致的結果
使用確定性函式
其它要求
示例
有關詳細資訊

什麼是索引檢視？

許多年來，Microsoft? SQL Server? 一直都提供建立虛擬表（稱為檢視）的功能。在過去，這些檢視主要有兩種用途：

提供安全機制，將使用者限制在一個或多個基表中的資料的某個子集。
提供一種機制，允許開發人員定製使用者如何才能以邏輯方式檢視儲存在基表中的資料。
SQL Server 2000 已經擴充套件了 SQL Server 檢視的功能，以提高系統效能。它可以在一個檢視上建立唯一的群集索引和非群集索引，可以改進最複雜查詢的資料訪問效能。在 SQL Server 2000 中，擁有唯一群集索引的檢視被稱為索引檢視。

注意： 索引檢視只是 SQL Server 2000 企業版和 SQL Server 2000 開發人員版的一個功能。

從資料庫管理系統 (DBMS) 的觀點來看，檢視是資料（後設資料）的說明。建立典型檢視時，透過 SELECT 語句（定義一個顯示為虛擬表的結果集）來定義後設資料。當其它查詢的 FROM 子句中引用了某個檢視時，將從系統目錄中檢索該後設資料，並對其進行擴充套件以代替該檢視的引用。在檢視擴充套件之後，查詢最佳化器會為正在執行的查詢編譯單個執行計劃。

如果是非索引檢視，檢視在執行時將被實體化。任何計算（如聯接或聚合）都在為每個引用該檢視的查詢執行查詢期間進行。（檢視並不總需要被完全實體化。查詢可以包含其它一些謂詞、聯接或聚合，以應用於該檢視所引用的表和檢視。）在檢視上建立了唯一的群集索引之後，檢視的結果集會立即被實體化並持續儲存在資料庫的物理儲存空間中，以便節省這種操作所佔用的大量資源。

在執行查詢時，有兩種方法可以使用索引檢視。查詢可直接引用索引檢視，更重要的是，如果查詢最佳化器確定檢視能夠替換為查詢的部分或全部，而且這是低成本的查詢計劃，則可以選擇索引檢視。第二種情況是使用索引檢視代替基礎表及其普通索引。此時，不需要在查詢中引用檢視，查詢最佳化器即可在執行查詢期間使用該檢視。這樣，現有的應用程式無需更改即可從新建的索引檢視中獲益。

透過索引檢視提高的效能

使用索引來提高查詢效能並不是什麼新觀念，不過，索引檢視還具有使用標準索引不能獲得的其它效能優點。索引檢視能夠在以下方面提高查詢效能：

能夠預先計算聚合並將其儲存在索引中，從而最大限度地減少在執行查詢期間進行成本很高的計算。
能夠預先聯接表並儲存生成的資料集。
能夠儲存聯接或聚合的組合。
下圖說明了查詢最佳化器使用索引檢視時一般能夠提高多少效能。提供的查詢複雜程度各不相同（例如，聚合計算的數量、所用表的數量或謂詞數），幷包括來自實際生產環境的數百萬行的大表。

圖 1. 當查詢最佳化器使用索引檢視時一般能夠提高多少效能

使用檢視的輔助索引

檢視的輔助性非群集索引可以提高其它查詢效能。與表的輔助索引類似，檢視的輔助索引也可以提供更多選項，以便查詢最佳化器在編譯過程中從中進行選擇。例如，如果查詢包括群集索引未涉及的列，最佳化器可以在計劃中選擇一個或多個輔助索引，從而避免對索引檢視或基表進行費時的全域性掃描。

由於索引需要不斷維護，所以為架構新增索引會增加資料庫的額外開銷。因此應該認真考慮，找到索引和維護額外開銷之間的平衡點。

使用索引檢視的好處

實現索引檢視之前，請先分析資料庫的工作量。運用自己對查詢以及各種工具（例如 SQL 分析器）的知識來鑑別使用索引檢視可以獲益的查詢。如果經常進行聚合和聯接，最好使用索引檢視。

並非所有查詢都會從索引檢視中獲益。與普通索引類似，如果未使用索引檢視，就沒有好處可言。在此情況下，不但不能提高效能，還會加大磁碟空間的佔用、增加維護和最佳化的成本。但是，如果使用了索引檢視，它們可以（成數量級地）明顯地提高資料訪問的效能。這是因為查詢最佳化器使用儲存在索引檢視中的預先計算的結果，從而大大降低了執行查詢的成本。

查詢最佳化器只在查詢的成本比較大時才考慮使用索引檢視。這樣可以避免在查詢最佳化成本超出因使用索引檢視而節省的成本時，試圖使用各種索引檢視。當查詢成本低於 1 時，幾乎不使用索引檢視。

使用索引檢視可以受益的應用包括：

決定支援工作量
資料集市
聯機分析處理 (OLAP) 庫和源
資料探勘工作量
從查詢的型別和模式的角度來看，受益的應用可被歸納為包含以下內容的應用：

大表的聯接和聚合
查詢的重複模式
重複聚合相同或重疊的列集
針對相同關鍵字重複聯接相同的表
上述的組合
相反，包含許多寫入的聯機事務處理 (OLTP) 系統或更新頻繁的資料庫，可能會因為要同時更新檢視和根本基表而使維護成本增加，所以不能利用索引檢視。

查詢最佳化器如何使用索引檢視

SQL Server 查詢最佳化器可自動確定何時可以將索引檢視用於給定的查詢執行中。查詢中無需直接引用檢視，最佳化器就可以將該檢視用於查詢執行計劃。因此，無需對現有的應用程式本身進行任何更改，這些應用程式即可利用索引檢視。唯一需要做的就是建立索引檢視。

最佳化器的考慮因素

查詢最佳化器會考慮幾個條件來確定索引檢視能涵蓋部分查詢還是整個查詢。這些條件符合查詢中的單個 FROM 子句幷包含以下內容：

查詢 FROM 子句中的表必須是索引檢視 FROM 子句中的表的超集。
查詢中的聯接條件必須是檢視中聯接條件的超集。
查詢中的聚合列必須是檢視中的聚合列的子集。
查詢選擇列表中的所有表示式都必須源自於檢視選擇列表或源自於不包括在檢視定義中的表。
查詢搜尋條件謂詞必須是檢視定義中搜尋條件謂詞的超集。檢視搜尋謂詞中的每個合取項都必須以同樣的形式出現在查詢搜尋謂詞中。
查詢搜尋條件謂詞中的所有列（屬於檢視定義中的表）都必須出現在下列一項或多項中：
檢視定義中的同一個謂詞。
GROUP BY 列表。
檢視選擇列表（若沒有 GROUP BY 列表）。
如果查詢包含多個 FROM 子句（子查詢、派生表、UNION），最佳化器可以選擇多個索引檢視來管理含有多個 FROM 子句的查詢。

注意： 也存在例外情形，即最佳化器可能將兩個 FROM 子句摺疊成一個（將子查詢摺疊成聯接或將派生表摺疊成聯接變體）。如果出現此類情況，索引檢視替換可能會涵蓋原查詢中的多個 FROM 子句。

本文件結尾介紹了演示這些條件的查詢示例。而建議的最佳方法就是：讓查詢最佳化器來確定在查詢執行計劃中使用哪些索引（如果有的話）。

使用 NOEXPAND 選項

NOEXPAND 選項強制查詢最佳化器象對待包含群集索引的普通表一樣對待檢視。在此情況下，必須在 FROM 子句中直接引用索引檢視。例如：

SELECT Column1, Column2, ... FROM Table1, View1 WITH (NOEXPAND)WHERE ...

使用 EXPAND VIEWS 選項

另外，使用者可以在查詢結束時透過使用 EXPAND VIEWS 選項，明確地將索引檢視排除在考慮之外。例如：

SELECT Column1, Column2, ... FROM Table1, View1 WHERE ...OPTION (EXPAND VIEWS)

如果使用該選項，查詢最佳化器在評估低成本的方法（該方法涉及查詢中引用的列）時將忽略所有檢視索引。

設計的考慮因素

為資料庫系統找到適當的索引集是相當複雜的。儘管在設計普通索引時要考慮許多可能性，但將索引檢視新增到架構會極大地增加設計和潛在結果的複雜性。例如，索引檢視可用於：

查詢中所引用表的任何子集。
查詢中條件的任何子集（屬於表的上述子集）
分組列。
聚合函式，如 SUM。
應同時設計表的索引和索引檢視，以便從各個結構中獲得最佳結果。由於索引和索引檢視都可能對給定的查詢有用，所以單獨設計它們會導致多餘的建議方案，以致儲存和維護開銷較高。在調整資料庫的物理設計時，必須均衡考慮各種查詢集的效能要求與資料庫系統必須支援的更新操作。因此，為索引檢視找到一種合理的物理設計是一項很具挑戰性的任務，因而應該儘可能地使用“索引微調嚮導”。

如果存在許多索引檢視可供查詢最佳化器考慮用於特定查詢，查詢最佳化成本會顯著增加。查詢最佳化器可能考慮為查詢中表的任意子集定義的所有索引檢視。拒絕每一個檢視之前，必須對它進行語法分析，然後研究其是否可能成為潛在的替換體。這可能需要一些時間，尤其是在有數百個此類的檢視用於給定的查詢時。

檢視必須符合幾項要求，您才能為其建立唯一的群集索引。在設計階段，請考慮以下要求：

檢視以及檢視中引用的所有表都必須在同一資料庫中，並具有同一個所有者。
索引檢視無需包含要供最佳化器使用的查詢中引用的所有表。
必須先為檢視建立唯一群集索引，然後才可以建立其它索引。
建立基表、檢視和索引以及修改基表和檢視中的資料時，必須正確設定某些 SET 選項（在本文件的後文中討論）。另外，如果這些 SET 選項正確，查詢最佳化器將不考慮索引檢視。
檢視必須使用架構繫結建立，檢視中引用的任何使用者定義的函式必須使用 SCHEMABINDING 選項建立。
另外，還要求有一定的磁碟空間來存放由索引檢視定義的資料。

設計準則

設計索引檢視時，請考慮以下準則：

設計的索引檢視必須能用於多個查詢或多個計算。
例如，包含某列的 SUM 和某列的 COUNT_BIG 的索引檢視可用於包含函式 SUM、COUNT、COUNT_BIG 或 AVG 的查詢。由於只需檢索檢視中的少數幾行，而不是基表中的所有行，且執行 AVG 函式要求的部分計算已經完成，所以查詢將比較快。

使索引保持緊湊。
透過使用最少的列數和儘可能少的位元組數，最佳化器在查詢行資料時可獲得最高的效率。相反，如果定義了大的群集索引關鍵字，則為檢視定義的任何輔助性非群集索引都將明顯增大，這是因為非群集索引項除包含索引定義的列之外，還將包含群集關鍵字。

考慮生成的索引檢視的大小。
在單純的聚合情況下，如果索引檢視的大小類似於原表的大小，使用索引檢視可能無法明顯提高任何效能。

設計多個較小的索引檢視來加快部分程式的速度。
有時可能無法設計出能滿足整個查詢需要的索引檢視。此時即可考慮建立這樣一些索引檢視，每個索引檢視執行一部分查詢。

考慮以下示例：

經常執行的查詢會聚合一個資料庫中的資料，再聚合另一個資料庫中的資料，然後聯接結果。由於索引檢視不能引用多個資料庫中的表，所以您不能設計一個檢視來執行整個程式。不過，可以為要進行聚合的每個資料庫建立索引檢視。如果最佳化器能夠將索引檢視與現有查詢相匹配，至少聚合處理將會因為不必記錄現有查詢而提高速度。儘管聯接處理不會加快，整個查詢的速度卻因使用了儲存在索引檢視中的聚合而加快。
經常執行的查詢會聚合多個表中的資料，然後使用 UNION 來將結果結合起來。UNION 不允許在索引檢視中使用。您可以設計一些檢視來執行每個單獨的聚合運算。然後最佳化器可以選擇索引檢視來加快查詢的速度，而無需記錄查詢。儘管 UNION 處理沒有改進，單個聚合程式卻得以改進。

使用“索引微調嚮導”

“索引微調嚮導”除建議使用基表的索引之外，還建議使用索引檢視。使用該向導可提高管理員確定索引和索引檢視相結合的能力，從而最佳化針對資料庫執行的典型混合查詢的效能。

由於“索引微調嚮導”強制使用所有必需的 SET 選項（以確保結果集的正確性），其索引檢視將會成功建立。不過，如果您的應用程式的選項沒有按照要求設定，可能無法利用這些檢視。對那些參與索引檢視定義的表執行的插入、更新或刪除操作可能會失敗。

維護索引檢視

SQL Server 自動維護索引檢視，這與維護任何其它索引的情況類似。對於普通索引而言，每個索引都直接連線到單個表。透過對基礎表執行每個 INSERT、UPDATE 或 DELETE 操作，索引相應地進行了更新，以便使儲存在該索引中的值始終與表一致。

索引檢視的維護與此類似。不過，如果檢視引用了多個表，則對這些表中的任何一個進行更新都需要更新索引檢視。與普通索引不同的是，對任何一個參與的表執行一次行插入操作都可能導致在索引檢視中進行多次行插入操作。更新和刪除操作的情況也是如此。因此，較之於維護表的索引，維護索引檢視的代價更為高昂。

在 SQL Server 2000 中，某些檢視可以更新。如果某個檢視可以更新，則使用 INSERT、UPDATE 和 DELETE 語句可透過該檢視直接修改根本基表。為某個檢視建立索引並不會妨礙該檢視的更新。有關可更新檢視的詳細資訊，請參閱關於 SQL Server 2000 的“SQL Server 聯機圖書”中的“透過檢視修改資料（英文）”。

維護成本的考慮因素

設計索引檢視時應該考慮以下幾點：

資料庫中需要有一個額外的儲存空間用於索引檢視。索引檢視的結果集以類似於典型表儲存空間的方式物理儲存在資料庫中。
SQL Server 自動維護檢視。因此，對定義檢視所據的基表的任何更改都可能引起檢視索引的一處或多處更改，從而導致維護開銷的增加。
一個檢視獲得的淨效能提高就是檢視提供的查詢執行節約總計與儲存和維護該檢視耗費的成本之間的差。

估計檢視將佔用的所需儲存空間要相對簡單一些。用 SQL 查詢分析器的“顯示估計的執行計劃”工具求檢視定義中 SELECT 語句的值。該工具將得出查詢返回的行數和行大小的近似值。將這兩個值相乘，即可估計出檢視的可能大小。不過這只是一個近似值。檢視索引的實際大小隻能透過建立檢視索引來精確得出。

從 SQL Server 執行的自動維護考慮因素的觀點出發，“顯示估計的執行計劃”的功能可能會對此開銷的影響有所瞭解。如果用 SQL 查詢分析器評估修改檢視的語句（針對檢視的 UPDATE 語句、針對基表的 INSERT 語句），SHOWPLAN 將包括該語句的維護操作。同時考慮此成本和此操作將在生產環境中發生的次數，可以指示檢視維護的可能成本。

通常建議對檢視或基表進行的任何修改和更新都應該儘可能地成批執行，而不要單獨進行。這樣可以減少檢視維護的某些開銷。

建立索引檢視

建立索引檢視所需的步驟與檢視的成功實現密不可分。

確保將在檢視中引用的所有現有表的 SET 選項都正確。
建立任何新表和檢視之前，確保會話的 SET 選項已正確設定。
確保檢視定義是確定的。
使用 WITH SCHEMABINDING 選項建立檢視。
建立檢視的唯一群集索引。

使用 SET 選項以獲得一致的結果

如果在執行查詢時啟用不同的 SET 選項，則在 SQL Server 中對同一個表示式求值會產生不同的結果。例如，將 SET 選項 CONCAT_NULL_YIELDS_NULL 設定為 ON 之後，表示式 'abc' + NULL 返回的值是 NULL。而將 CONCAT_NULL_YIEDS_NULL 設定為 OFF 之後，該表示式得出的結果卻是 'abc'。索引檢視要求多個 SET 選項的值都固定，以確保這些檢視能夠得到正確維護並返回一致的結果。

只要出現以下情況，就必須將下表中的 SET 選項設定為要求的值列中所示的值：

建立了索引檢視。
對索引檢視中引用的任何表執行了任何 INSERT、UPDATE 或 DELETE 操作。
查詢最佳化器使用索引檢視來生成查詢計劃。
SET
選項 要求
的值 預設
伺服器
的值 OLE DB
和
ODBC 的值 DB LIB
的值
ANSI_NULLS ON OFF ON OFF
ANSI_PADDING ON ON ON OFF
ANSI_WARNING ON OFF ON OFF
ARITHABORT ON OFF OFF OFF
CONCAT_NULL_YIELDS_NULL ON OFF ON OFF
NUMERIC_ROUNDABORT OFF OFF OFF OFF
QUOTED_IDENTIFIER ON OFF ON OFF

如果使用的是 OLE DB 或 ODBC 伺服器連線，唯一必須修改的值是 ARITHABORT 的設定。所有 DB LIB 值都必須使用 sp_configure 在伺服器級上正確設定或使用 SET 命令從應用程式正確設定。有關 SET 選項的詳細資訊，請參閱關於 SQL Server 2000 的“SQL Server 聯機圖書”中的“使用 SQL Server 中的選項（英文）”。

使用確定性函式

索引檢視的定義必須是確定性的。如果選擇列表中的所有表示式以及 WHERE 和 GROUP BY 子句都是確定性的，則檢視就是確定性的。只要用特定的一組輸入值對確定性表示式進行求值，一定會返回同一個結果。只有確定性函式可以加入確定性表示式。例如，DATEADD 是確定性函式，因為將任何給定的一組變數值賦予它的三個引數進行求值，返回的總是同一個結果。而 GETDATE 則不是確定性函式，因為始終用同一個變數呼叫它，而它每次執行後返回的值都不相同。有關詳細資訊，請參閱關於 SQL Server 2000 的“SQL Server 聯機圖書”中的“確定性和非確定性函式”。

即便某個表示式是確定性的，但如果其中包含浮動表示式，確切的結果就可能取決於處理器的體系結構或微程式碼的版本。要確保 SQL Server 2000 中資料的完整性，此類表示式只能加入索引檢視的非關鍵列。不包含浮動表示式的確定性表示式被稱為精確的表示式。只有精確的確定性表示式可以加入索引檢視的關鍵列和 WHERE 或 GROUP BY 子句。

使用 COLUMNPROPERTY 函式和 IsDeterministic 屬性來確定檢視列是否是確定性的。使用 COLUMNPROPERTY 函式和 IsPrecise 屬性來確定包含架構繫結的檢視中的確定性列是否是精確的。如果為 TRUE，則 COLUMNPROPERTY 會返回 1，如果為 FALSE，則返回 0，如果是無效的輸入（列不是確定性的），則返回 NULL。例如，SELECT COLUMNPROPERTY(Object_Id('Vdiscount1'),'SumDiscountPrice','IsPrecise') 返回的是 0，因為 SumDiscountPrice 列引用了表 Order Details 中的浮動列 Discount。而同一檢視中的列 SumPrice 既是確定性的又是精確的。

注意： 該 SELECT 語句所基於的檢視能夠在示例部分找到（檢視 1）。

其它要求

除“設計準則”、“使用 SET 選項以獲得一致的結果”和“使用確定性函式”部分中列出的要求之外，還必須符合以下要求。

基表要求

基表在建立時必須正確設定 SET 選項，否則就不能被包含架構繫結的檢視引用。
表必須透過檢視定義中的兩部分名稱（所有者.表名）引用。
函式要求

使用者定義的函式必須使用 WITH SCHEMABINDING 選項建立。
使用者定義的函式必須透過兩部分名稱（所有者.函式）引用。
檢視要求

檢視必須使用 WITH SCHEMABINDING 選項建立。
檢視必須只引用同一資料庫中的基表，而不能引用其它檢視。
語法限制

對檢視定義的語法有幾個限制。檢視定義不能包含以下內容：

COUNT(*)
ROWSET 函式
派生表
自聯接
DISTINCT
STDEV、VARIANCE、AVG
Float* 列、文字列、ntext 列、影像列
子查詢
全文謂詞（CONTAIN、FREETEXT）
可空表示式的 SUM
MIN、MAX
TOP
OUTER 聯接
UNION
注意： 索引檢視可以包含浮動列，不過，此類列不能包含在群集索引關鍵字中。

GROUP BY 限制

如果未使用 GROUP BY，表示式不能在選擇列表中使用。

如果使用了 GROUP BY，則 VIEW 定義：

必須包含 COUNT_BIG(*)。
不得包含 HAVING、CUBE 或 ROLLUP。
這些限制只適用於索引檢視定義。查詢可以在其執行計劃中使用索引檢視，即便該索引檢視並不符合這些 GROUP BY 限制。

索引要求

執行 CREATE INDEX 語句的使用者必須是檢視所有者。
如果檢視定義中包含 GROUP BY 子句，唯一群集索引的關鍵字只能引用 GROUP BY 子句中指定的列。

示例

本部分的示例闡述索引檢視在兩種主要查詢（聚合和聯接）中的使用問題。同時還說明查詢最佳化器在確定某個索引檢視是否可用時使用的條件。有關這些條件的完整列表，請參閱查詢最佳化器如何使用索引檢視。

查詢基於 Northwind（SQL Server 2000 中提供的資料庫樣本）中的表，並可以寫入的方式執行。建立檢視的前後，最好使用 SQL 查詢最佳化器中的“顯示執行計劃”工具來檢視查詢最佳化器選定的計劃。儘管示例中闡述了最佳化器是如何選擇成本最低的執行計劃的，但因為 Northwind 資料庫樣本太小，因此無法體現效能的提高。

以下查詢顯示如何從 Order Details 表中返回具有最大總折扣的五種產品的兩個方法。

查詢 1

SELECT TOP 5 ProductID, SUM(UnitPrice*Quantity) -
SUM(UnitPrice*Quantity*(1.00-Discount))AS Rebate
FROM [Order Details]
GROUP BY ProductID
ORDER BY Rebate DESC

查詢 2

SELECT TOP 5 ProductID, SUM(UnitPrice*Quantity*Discount)AS Rebate
FROM [Order Details]
GROUP BY ProductID
ORDER BY Rebate DESC

查詢最佳化器選定的執行計劃包含：

對 Order Details 表的群集索引掃描，估計有 2,155 行。
雜湊匹配/聚合運算子，該運算子基於 GROUP BY 列將選定的行放入雜湊表，然後計算每行的 SUM 聚合。
基於 ORDER BY 子句的 TOP 5 排序運算子。
檢視 1

新增包括 Rebate 列所需聚合的索引檢視將更改查詢 1 的查詢執行計劃。在數百萬行的大表上，查詢的效能也將明顯提高。

CREATE VIEW Vdiscount1 WITH SCHEMABINDING
AS
SELECT SUM(UnitPrice*Quantity)AS SumPrice,
SUM(UnitPrice*Quantity*(1.00-Discount))
AS SumDiscountPrice, COUNT_BIG(*) AS Count, ProductID
FROM dbo.[Order Details]
GROUP BY ProductID
GO
CREATE UNIQUE CLUSTERED INDEX VDiscountInd ON Vdiscount1 (ProductID)

第一個查詢的執行計劃顯示 Vdiscount1 檢視由查詢最佳化器使用。不過，由於該檢視不包含 SUM(UnitPrice*Quantity*Discount) 聚合，因此不會被第二個查詢使用。可以建立另一個可以同時滿足上述兩個查詢的索引檢視。

檢視 2

CREATE VIEW Vdiscount2 WITH SCHEMABINDING
AS
SELECT SUM(UnitPrice*Quantity)AS SumPrice,
SUM(UnitPrice*Quantity*(1.00-Discount))AS SumDiscountPrice,
SUM(UnitPrice*Quantity*Discount)AS SumDiscountPrice2, COUNT_BIG(*)
AS Count, ProductID
FROM dbo.[Order Details]
GROUP BY ProductID
GO
CREATE UNIQUE CLUSTERED INDEX VDiscountInd ON Vdiscount2 (ProductID)

有了該索引檢視，現在兩個查詢的查詢執行計劃包含：

對 Vdiscount2 檢視的群集索引掃描，估計有 77 行
基於 ORDER BY 子句的 TOP 5 排序函式
查詢最佳化器選擇該檢視是因為它提供了最低的執行成本，儘管在查詢中並未引用該檢視。

查詢 3

查詢 3 類似於前幾個查詢，只是 ProductID 已被 OrderID 所取代，檢視定義中沒有包括該列。這違背了以下條件：查詢選擇列表中的所有表示式都必須能從未包括在檢視定義內的表的檢視選擇列表中派生。

SELECT TOP 3 OrderID, SUM(UnitPrice*Quantity*Discount) OrderRebate
FROM dbo.[Order Details]
GROUP BY OrderID
ORDER BY OrderRebate desc

要求單獨的索引檢視來滿足該查詢。可以對 Vdiscount2 進行修改，使它包括 OrderID，但是所生成檢視的行數將與原表的行數相同，因此，提供的效能也不會高於使用基表所提供的效能。

查詢 4

該查詢可生成每個產品的平均價格。

SELECT ProductName, od.ProductID,
AVG(od.UnitPrice*(1.00-Discount)) AS AvgPrice, SUM(od.Quantity) AS Units
FROM [Order Details] od, Products p
WHERE od.ProductID=p.ProductID
GROUP BY ProductName, od.ProductID

索引檢視的定義中不能包括複雜的聚合（例如，STDEV、VARIANCE、AVG），不過，如果索引檢視中包括幾個聯合起來執行復雜聚合的簡單聚合函式，即可用於執行包含 AVG 的查詢。

檢視 3

該索引檢視包含執行 AVG 函式所需的簡單聚合函式。在建立了檢視 3 後執行查詢 4 時，執行計劃會顯示正被使用的檢視。最佳化器可以從檢視的簡單聚合列 Price 和 Count 中匯出 AVG 表示式。

CREATE VIEW View3 WITH SCHEMABINDING
AS
SELECT ProductID, SUM(UnitPrice*(1.00-Discount))AS Price,
COUNT_BIG(*)AS Count, SUM(Quantity)AS Units
FROM dbo.[Order Details]
GROUP BY ProductID
Go
CREATE UNIQUE CLUSTERED INDEX iv3 ON View3 (ProductID)

查詢 5

該查詢與查詢 4 相同，只不過包括一個附加搜尋條件。即使該附加搜尋條件只引用未包括在檢視定義內的表中的列，檢視 3 也將用於該查詢。

SELECT ProductName, od.ProductID, AVG(od.UnitPrice*(1.00-Discount))
AS AvgPrice, SUM(od.Quantity)AS Units
FROM [Order Details] AS od, Products AS p
WHERE od.ProductID=p.ProductID
AND p.ProductName like '%Tofu%'
GROUP BY ProductName, od.ProductID

查詢 6

查詢最佳化器不能將檢視 3 用於該查詢。附加搜尋條件 od.UnitPrice>10 包含檢視定義內的表中的列，而該列卻不出現在 GROUP BY 列表中，搜尋謂詞也不出現在檢視定義中。

SELECT ProductName, od.ProductID, AVG(od.UnitPrice*(1.00-Discount))
AS AvgPrice, SUM(od.Quantity) AS Units
FROM [Order Details] od, Products p
WHERE od.ProductID = p.ProductID
AND od.UnitPrice > 10
GROUP BY ProductName, od.ProductID

查詢 7

相反，查詢最佳化器可以將檢視 3 用於查詢 7，原因是新搜尋條件 od.ProductID in (1,2,13,41) 中定義的列包括在檢視定義內的 GROUP BY 子句中。

SELECT ProductName, od.ProductID, AVG(od.UnitPrice*(1.00-Discount))
AS AvgPrice, SUM(od.Quantity) AS Units
FROM [Order Details] AS od, Products AS p
WHERE od.ProductID = p.ProductID
AND od.ProductID in (1,2,13,41)
GROUP BY ProductName, od.ProductID

檢視 4

該檢視在檢視定義中包括了列 od.Discount，可以滿足查詢 6 的條件。

CREATE VIEW View4 WITH SCHEMABINDING
AS
SELECT ProductName, od.ProductID, SUM(od.UnitPrice*(1.00-Discount))
AS AvgPrice, SUM(od.Quantity) AS Units, COUNT_BIG(*) AS Count
FROM dbo.[Order Details] AS od, dbo.Products AS p
WHERE od.ProductID = p.ProductID
AND od.UnitPrice > 10
GROUP BY ProductName, od.ProductID
GO
CREATE UNIQUE CLUSTERED INDEX VdiscountInd on View4 (ProductName, ProductID)

查詢 8

檢視 4 的同一個索引還將用於一個新增了與表 Orders 的聯接的查詢。該查詢符合以下條件：查詢 FROM 子句中列出的表是索引檢視的 FROM 子句中表的超集。

SELECT ProductName, od.ProductID, AVG(od.UnitPrice*(1.00-Discount))
AS AvgPrice, SUM(od.Quantity) AS Units
FROM dbo.[Order Details] AS od, dbo.Products AS p, dbo.Orders AS o
WHERE od.ProductID = p.ProductID and o.OrderID = od.OrderID
AND od.UnitPrice > 10
GROUP BY ProductName, od.ProductID

最後兩個查詢是查詢 8 的變體。每個變體都違背了一個最佳化器條件，因此與查詢 8 不同，不能使用檢視 4。

查詢 8a

由於檢視定義中的 UnitPrice > 10 與查詢中的 UnitPrice > 25 之間的 WHERE 子句不匹配，所以 Q8a 不能使用索引檢視。查詢搜尋條件謂詞必須是檢視定義中搜尋條件謂詞的超集。

SELECT ProductName, od.ProductID, AVG(od.UnitPrice*(1.00-Discount)) AvgPrice,
SUM(od.Quantity) AS Units
FROM dbo.[Order Details] AS od, dbo.Products AS p, dbo.Orders AS o
WHERE od.ProductID = p.ProductID and o.OrderID = od.OrderID
AND od.UnitPrice > 25
GROUP BY ProductName, od.ProductID

查詢 8b

注意，表 Orders 沒有參與索引檢視 V4 的定義。儘管如此，在該表中新增謂詞將禁止使用索引檢視，原因是新增的謂詞可能會消除聚合中的其它行（如查詢 8b 中所示）。

SELECT ProductName, od.ProductID, AVG(od.UnitPrice*(1.00-Discount))
AS AvgPrice, SUM(od.Quantity) AS Units
FROM dbo.[Order Details] AS od, dbo.Products AS p, dbo.Orders AS o
WHERE od.ProductID = p.ProductID and o.OrderID = od.OrderID
AND od.UnitPrice > 10
AND o.OrderDate > '01/01/1998'
GROUP BY ProductName, od.ProductID