使用SQL Server 2000索引視圖提高性能
作者：Gail Erickson
摘要：本文檔介紹 SQL Server 2000 企業(yè)版的新功能 - 索引視圖。講解索引視圖并討論一些提高性能的具體方案。
什么是索引視圖？
許多年來，Microsoft？ SQL Server？ 一直都提供創(chuàng)建虛擬表（稱為視圖）的功能。在過去，這些視圖主要有兩種用途：
提供安全機制，將用戶限制在一個或多個基表中的數(shù)據(jù)的某個子集。
提供一種機制，允許開發(fā)人員定制用戶如何才能以邏輯方式查看存儲在基表中的數(shù)據(jù)。
SQL Server 2000 已經(jīng)擴展了 SQL Server 視圖的功能，以提高系統(tǒng)性能。它可以在一個視圖上創(chuàng)建唯一的群集索引和非群集索引，可以改進最復雜查詢的數(shù)據(jù)訪問性能。在 SQL Server 2000 中，擁有唯一群集索引的視圖被稱為索引視圖。
注意： 索引視圖只是 SQL Server 2000 企業(yè)版和 SQL Server 2000 開發(fā)人員版的一個功能。
從數(shù)據(jù)庫管理系統(tǒng) （DBMS） 的觀點來看，視圖是數(shù)據(jù)（元數(shù)據(jù)）的說明。創(chuàng)建典型視圖時，通過 SELECT 語句（定義一個顯示為虛擬表的結(jié)果集）來定義元數(shù)據(jù)。當其它查詢的 FROM 子句中引用了某個視圖時，將從系統(tǒng)目錄中檢索該元數(shù)據(jù)，并對其進行擴展以代替該視圖的引用。在視圖擴展之后，查詢優(yōu)化器會為正在執(zhí)行的查詢編譯單個執(zhí)行計劃。
如果是非索引視圖，視圖在運行時將被實體化。任何計算（如聯(lián)接或聚合）都在為每個引用該視圖的查詢執(zhí)行查詢期間進行。（視圖并不總需要被完全實體化。查詢可以包含其它一些謂詞、聯(lián)接或聚合，以應用于該視圖所引用的表和視圖。）在視圖上創(chuàng)建了唯一的群集索引之后，視圖的結(jié)果集會立即被實體化并持續(xù)保存在數(shù)據(jù)庫的物理存儲空間中，以便節(jié)省這種操作所占用的大量資源。
在執(zhí)行查詢時，有兩種方法可以使用索引視圖。查詢可直接引用索引視圖，更重要的是，如果查詢優(yōu)化器確定視圖能夠替換為查詢的部分或全部，而且這是低成本的查詢計劃，則可以選擇索引視圖。第二種情況是使用索引視圖代替基礎(chǔ)表及其普通索引。此時，不需要在查詢中引用視圖，查詢優(yōu)化器即可在執(zhí)行查詢期間使用該視圖。這樣，現(xiàn)有的應用程序無需更改即可從新建的索引視圖中獲益。
通過索引視圖提高的性能
使用索引來提高查詢性能并不是什么新觀念，不過，索引視圖還具有使用標準索引不能獲得的其它性能優(yōu)點。索引視圖能夠在以下方面提高查詢性能：
能夠預先計算聚合并將其存儲在索引中，從而最大限度地減少在執(zhí)行查詢期間進行成本很高的計算。
能夠預先聯(lián)接表并存儲生成的數(shù)據(jù)集。
能夠存儲聯(lián)接或聚合的組合。
使用視圖的輔助索引
視圖的輔助性非群集索引可以提高其它查詢性能。與表的輔助索引類似，視圖的輔助索引也可以提供更多選項，以便查詢優(yōu)化器在編譯過程中從中進行選擇。例如，如果查詢包括群集索引未涉及的列，優(yōu)化器可以在計劃中選擇一個或多個輔助索引，從而避免對索引視圖或基表進行費時的全局掃描。
由于索引需要不斷維護，所以為架構(gòu)添加索引會增加數(shù)據(jù)庫的額外開銷。因此應該認真考慮，找到索引和維護額外開銷之間的平衡點。
使用索引視圖的好處
實現(xiàn)索引視圖之前，請先分析數(shù)據(jù)庫的工作量。運用自己對查詢以及各種工具（例如 SQL 分析器）的知識來鑒別使用索引視圖可以獲益的查詢。如果經(jīng)常進行聚合和聯(lián)接，最好使用索引視圖。
并非所有查詢都會從索引視圖中獲益。與普通索引類似，如果未使用索引視圖，就沒有好處可言。在此情況下，不但不能提高性能，還會加大磁盤空間的占用、增加維護和優(yōu)化的成本。但是，如果使用了索引視圖，它們可以（成數(shù)量級地）明顯地提高數(shù)據(jù)訪問的性能。這是因為查詢優(yōu)化器使用存儲在索引視圖中的預先計算的結(jié)果，從而大大降低了執(zhí)行查詢的成本。
查詢優(yōu)化器只在查詢的成本比較大時才考慮使用索引視圖。這樣可以避免在查詢優(yōu)化成本超出因使用索引視圖而節(jié)省的成本時，試圖使用各種索引視圖。當查詢成本低于 1 時，幾乎不使用索引視圖。
使用索引視圖可以受益的應用包括：
決定支持工作量
數(shù)據(jù)集市
聯(lián)機分析處理 （OLAP） 庫和源
數(shù)據(jù)挖掘工作量
從查詢的類型和模式的角度來看，受益的應用可被歸納為包含以下內(nèi)容的應用：
大表的聯(lián)接和聚合
查詢的重復模式
重復聚合相同或重疊的列集
針對相同關(guān)鍵字重復聯(lián)接相同的表
上述的組合
相反，包含許多寫入的聯(lián)機事務(wù)處理 （OLTP） 系統(tǒng)或更新頻繁的數(shù)據(jù)庫，可能會因為要同時更新視圖和根本基表而使維護成本增加，所以不能利用索引視圖。
查詢優(yōu)化器如何使用索引視圖
SQL Server 查詢優(yōu)化器可自動確定何時可以將索引視圖用于給定的查詢執(zhí)行中。查詢中無需直接引用視圖，優(yōu)化器就可以將該視圖用于查詢執(zhí)行計劃。因此，無需對現(xiàn)有的應用程序本身進行任何更改，這些應用程序即可利用索引視圖。唯一需要做的就是創(chuàng)建索引視圖。
優(yōu)化器的考慮因素
查詢優(yōu)化器會考慮幾個條件來確定索引視圖能涵蓋部分查詢還是整個查詢。這些條件符合查詢中的單個 FROM 子句并包含以下內(nèi)容：
查詢 FROM 子句中的表必須是索引視圖 FROM 子句中的表的超集。
查詢中的聯(lián)接條件必須是視圖中聯(lián)接條件的超集。
查詢中的聚合列必須是視圖中的聚合列的子集。
查詢選擇列表中的所有表達式都必須源自于視圖選擇列表或源自于不包括在視圖定義中的表。
查詢搜索條件謂詞必須是視圖定義中搜索條件謂詞的超集。視圖搜索謂詞中的每個合取項都必須以同樣的形式出現(xiàn)在查詢搜索謂詞中。
查詢搜索條件謂詞中的所有列（屬于視圖定義中的表）都必須出現(xiàn)在下列一項或多項中：
視圖定義中的同一個謂詞。
GROUP BY 列表。
視圖選擇列表（若沒有 GROUP BY 列表）。
如果查詢包含多個 FROM 子句（子查詢、派生表、UNION），優(yōu)化器可以選擇多個索引視圖來管理含有多個 FROM 子句的查詢。
注意： 也存在例外情形，即優(yōu)化器可能將兩個 FROM 子句折疊成一個（將子查詢折疊成聯(lián)接或?qū)⑴缮碚郫B成聯(lián)接變體）。如果出現(xiàn)此類情況，索引視圖替換可能會涵蓋原查詢中的多個 FROM 子句。
本文檔結(jié)尾介紹了演示這些條件的查詢示例。而建議的最佳方法就是：讓查詢優(yōu)化器來確定在查詢執(zhí)行計劃中使用哪些索引（如果有的話）。
使用 NOEXPAND 選項
NOEXPAND 選項強制查詢優(yōu)化器象對待包含群集索引的普通表一樣對待視圖。在此情況下，必須在 FROM 子句中直接引用索引視圖。例如：
SELECT Column1， Column2， .。。 FROM Table1， View1 WITH （NOEXPAND）WHERE .。。
使用 EXPAND VIEWS 選項
另外，用戶可以在查詢結(jié)束時通過使用 EXPAND VIEWS 選項，明確地將索引視圖排除在考慮之外。例如：
SELECT Column1， Column2， .。。 FROM Table1， View1 WHERE .。。OPTION （EXPAND VIEWS）
如果使用該選項，查詢優(yōu)化器在評估低成本的方法（該方法涉及查詢中引用的列）時將忽略所有視圖索引。
設(shè)計的考慮因素
為數(shù)據(jù)庫系統(tǒng)找到適當?shù)乃饕窍喈攺碗s的。盡管在設(shè)計普通索引時要考慮許多可能性，但將索引視圖添加到架構(gòu)會極大地增加設(shè)計和潛在結(jié)果的復雜性。例如，索引視圖可用于：
查詢中所引用表的任何子集。
查詢中條件的任何子集（屬于表的上述子集）
分組列。
聚合函數(shù)，如 SUM.
應同時設(shè)計表的索引和索引視圖，以便從各個結(jié)構(gòu)中獲得最佳結(jié)果。由于索引和索引視圖都可能對給定的查詢有用，所以單獨設(shè)計它們會導致多余的建議方案，以致存儲和維護開銷較高。在調(diào)整數(shù)據(jù)庫的物理設(shè)計時，必須均衡考慮各種查詢集的性能要求與數(shù)據(jù)庫系統(tǒng)必須支持的更新操作。因此，為索引視圖找到一種合理的物理設(shè)計是一項很具挑戰(zhàn)性的任務(wù)，因而應該盡可能地使用“索引微調(diào)向?qū)А薄?/p>
如果存在許多索引視圖可供查詢優(yōu)化器考慮用于特定查詢，查詢優(yōu)化成本會顯著增加。查詢優(yōu)化器可能考慮為查詢中表的任意子集定義的所有索引視圖。拒絕每一個視圖之前，必須對它進行語法分析，然后研究其是否可能成為潛在的替換體。這可能需要一些時間，尤其是在有數(shù)百個此類的視圖用于給定的查詢時。
視圖必須符合幾項要求，您才能為其創(chuàng)建唯一的群集索引。在設(shè)計階段，請考慮以下要求：
視圖以及視圖中引用的所有表都必須在同一數(shù)據(jù)庫中，并具有同一個所有者。
索引視圖無需包含要供優(yōu)化器使用的查詢中引用的所有表。
必須先為視圖創(chuàng)建唯一群集索引，然后才可以創(chuàng)建其它索引。
創(chuàng)建基表、視圖和索引以及修改基表和視圖中的數(shù)據(jù)時，必須正確設(shè)置某些 SET 選項（在本文檔的后文中討論）。另外，如果這些 SET 選項正確，查詢優(yōu)化器將不考慮索引視圖。
視圖必須使用架構(gòu)綁定創(chuàng)建，視圖中引用的任何用戶定義的函數(shù)必須使用 SCHEMABINDING 選項創(chuàng)建。
另外，還要求有一定的磁盤空間來存放由索引視圖定義的數(shù)據(jù)。
設(shè)計準則
設(shè)計索引視圖時，請考慮以下準則：
設(shè)計的索引視圖必須能用于多個查詢或多個計算。
例如，包含某列的 SUM 和某列的 COUNT_BIG 的索引視圖可用于包含函數(shù) SUM、COUNT、COUNT_BIG 或 AVG 的查詢。由于只需檢索視圖中的少數(shù)幾行，而不是基表中的所有行，且執(zhí)行 AVG 函數(shù)要求的部分計算已經(jīng)完成，所以查詢將比較快。
使索引保持緊湊。
通過使用最少的列數(shù)和盡可能少的字節(jié)數(shù)，優(yōu)化器在查找行數(shù)據(jù)時可獲得最高的效率。相反，如果定義了大的群集索引關(guān)鍵字，則為視圖定義的任何輔助性非群集索引都將明顯增大，這是因為非群集索引項除包含索引定義的列之外，還將包含群集關(guān)鍵字。
考慮生成的索引視圖的大小。
在單純的聚合情況下，如果索引視圖的大小類似于原表的大小，使用索引視圖可能無法明顯提高任何性能。
設(shè)計多個較小的索引視圖來加快部分進程的速度。
有時可能無法設(shè)計出能滿足整個查詢需要的索引視圖。此時即可考慮創(chuàng)建這樣一些索引視圖，每個索引視圖執(zhí)行一部分查詢。
考慮以下示例：
經(jīng)常執(zhí)行的查詢會聚合一個數(shù)據(jù)庫中的數(shù)據(jù)，再聚合另一個數(shù)據(jù)庫中的數(shù)據(jù)，然后聯(lián)接結(jié)果。由于索引視圖不能引用多個數(shù)據(jù)庫中的表，所以您不能設(shè)計一個視圖來執(zhí)行整個進程。不過，可以為要進行聚合的每個數(shù)據(jù)庫創(chuàng)建索引視圖。如果優(yōu)化器能夠?qū)⑺饕晥D與現(xiàn)有查詢相匹配，至少聚合處理將會因為不必記錄現(xiàn)有查詢而提高速度。盡管聯(lián)接處理不會加快，整個查詢的速度卻因使用了存儲在索引視圖中的聚合而加快。
經(jīng)常執(zhí)行的查詢會聚合多個表中的數(shù)據(jù)，然后使用 UNION 來將結(jié)果結(jié)合起來。UNION 不允許在索引視圖中使用。您可以設(shè)計一些視圖來執(zhí)行每個單獨的聚合運算。然后優(yōu)化器可以選擇索引視圖來加快查詢的速度，而無需記錄查詢。盡管 UNION 處理沒有改進，單個聚合進程卻得以改進。
使用“索引微調(diào)向?qū)А?/p>
“索引微調(diào)向?qū)А背ㄗh使用基表的索引之外，還建議使用索引視圖。使用該向?qū)Э商岣吖芾韱T確定索引和索引視圖相結(jié)合的能力，從而優(yōu)化針對數(shù)據(jù)庫執(zhí)行的典型混合查詢的性能。
由于“索引微調(diào)向?qū)А睆娭剖褂盟斜匦璧?SET 選項（以確保結(jié)果集的正確性），其索引視圖將會成功創(chuàng)建。不過，如果您的應用程序的選項沒有按照要求設(shè)置，可能無法利用這些視圖。對那些參與索引視圖定義的表執(zhí)行的插入、更新或刪除操作可能會失敗。
維護索引視圖
SQL Server 自動維護索引視圖，這與維護任何其它索引的情況類似。對于普通索引而言，每個索引都直接連接到單個表。通過對基礎(chǔ)表執(zhí)行每個 INSERT、UPDATE 或 DELETE 操作，索引相應地進行了更新，以便使存儲在該索引中的值始終與表一致。
索引視圖的維護與此類似。不過，如果視圖引用了多個表，則對這些表中的任何一個進行更新都需要更新索引視圖。與普通索引不同的是，對任何一個參與的表執(zhí)行一次行插入操作都可能導致在索引視圖中進行多次行插入操作。更新和刪除操作的情況也是如此。因此，較之于維護表的索引，維護索引視圖的代價更為高昂。
在 SQL Server 2000 中，某些視圖可以更新。如果某個視圖可以更新，則使用 INSERT、UPDATE 和 DELETE 語句可通過該視圖直接修改根本基表。為某個視圖創(chuàng)建索引并不會妨礙該視圖的更新。有關(guān)可更新視圖的詳細信息，請參閱關(guān)于 SQL Server 2000 的“SQL Server 聯(lián)機圖書”中的“通過視圖修改數(shù)據(jù)（英文）”。
維護成本的考慮因素
設(shè)計索引視圖時應該考慮以下幾點：
數(shù)據(jù)庫中需要有一個額外的存儲空間用于索引視圖。索引視圖的結(jié)果集以類似于典型表存儲空間的方式物理保存在數(shù)據(jù)庫中。
SQL Server 自動維護視圖。因此，對定義視圖所據(jù)的基表的任何更改都可能引起視圖索引的一處或多處更改，從而導致維護開銷的增加。
一個視圖獲得的凈性能提高就是視圖提供的查詢執(zhí)行節(jié)約總計與存儲和維護該視圖耗費的成本之間的差。
估計視圖將占用的所需存儲空間要相對簡單一些。用 SQL 查詢分析器的“顯示估計的執(zhí)行計劃”工具求視圖定義中 SELECT 語句的值。該工具將得出查詢返回的行數(shù)和行大小的近似值。將這兩個值相乘，即可估計出視圖的可能大小。不過這只是一個近似值。視圖索引的實際大小只能通過創(chuàng)建視圖索引來精確得出。
從 SQL Server 執(zhí)行的自動維護考慮因素的觀點出發(fā)，“顯示估計的執(zhí)行計劃”的功能可能會對此開銷的影響有所了解。如果用 SQL 查詢分析器評估修改視圖的語句（針對視圖的 UPDATE 語句、針對基表的 INSERT 語句），SHOWPLAN 將包括該語句的維護操作。同時考慮此成本和此操作將在生產(chǎn)環(huán)境中發(fā)生的次數(shù)，可以指示視圖維護的可能成本。
通常建議對視圖或基表進行的任何修改和更新都應該盡可能地成批執(zhí)行，而不要單獨進行。這樣可以減少視圖維護的某些開銷。
創(chuàng)建索引視圖
創(chuàng)建索引視圖所需的步驟與視圖的成功實現(xiàn)密不可分。
確保將在視圖中引用的所有現(xiàn)有表的 SET 選項都正確。
創(chuàng)建任何新表和視圖之前，確保會話的 SET 選項已正確設(shè)置。
確保視圖定義是確定的。
使用 WITH SCHEMABINDING 選項創(chuàng)建視圖。
創(chuàng)建視圖的唯一群集索引。
使用 SET 選項以獲得一致的結(jié)果
如果在執(zhí)行查詢時啟用不同的 SET 選項，則在 SQL Server 中對同一個表達式求值會產(chǎn)生不同的結(jié)果。例如，將 SET 選項 CONCAT_NULL_YIELDS_NULL 設(shè)置為 ON 之后，表達式 'abc' + NULL 返回的值是 NULL.而將 CONCAT_NULL_YIEDS_NULL 設(shè)置為 OFF 之后，該表達式得出的結(jié)果卻是 'abc'.索引視圖要求多個 SET 選項的值都固定，以確保這些視圖能夠得到正確維護并返回一致的結(jié)果。
只要出現(xiàn)以下情況，就必須將下表中的 SET 選項設(shè)置為要求的值列中所示的值：
創(chuàng)建了索引視圖。
對索引視圖中引用的任何表執(zhí)行了任何 INSERT、UPDATE 或 DELETE 操作。
查詢優(yōu)化器使用索引視圖來生成查詢計劃。
如果使用的是 OLE DB 或 ODBC 服務(wù)器連接，唯一必須修改的值是 ARITHABORT 的設(shè)置。所有 DB LIB 值都必須使用 sp_configure 在服務(wù)器級上正確設(shè)置或使用 SET 命令從應用程序正確設(shè)置。有關(guān) SET 選項的詳細信息，請參閱關(guān)于 SQL Server 2000 的“SQL Server 聯(lián)機圖書”中的“使用 SQL Server 中的選項（英文）”。
使用確定性函數(shù)
索引視圖的定義必須是確定性的。如果選擇列表中的所有表達式以及 WHERE 和 GROUP BY 子句都是確定性的，則視圖就是確定性的。只要用特定的一組輸入值對確定性表達式進行求值，一定會返回同一個結(jié)果。只有確定性函數(shù)可以加入確定性表達式。例如，DATEADD 是確定性函數(shù)，因為將任何給定的一組變量值賦予它的三個參數(shù)進行求值，返回的總是同一個結(jié)果。而 GETDATE 則不是確定性函數(shù)，因為始終用同一個變量調(diào)用它，而它每次執(zhí)行后返回的值都不相同。有關(guān)詳細信息，請參閱關(guān)于 SQL Server 2000 的“SQL Server 聯(lián)機圖書”中的“確定性和非確定性函數(shù)”。
即便某個表達式是確定性的，但如果其中包含浮動表達式，確切的結(jié)果就可能取決于處理器的體系結(jié)構(gòu)或微代碼的版本。要確保 SQL Server 2000 中數(shù)據(jù)的完整性，此類表達式只能加入索引視圖的非關(guān)鍵列。不包含浮動表達式的確定性表達式被稱為精確的表達式。只有精確的確定性表達式可以加入索引視圖的關(guān)鍵列和 WHERE 或 GROUP BY 子句。
使用 COLUMNPROPERTY 函數(shù)和 IsDeterministic 屬性來確定視圖列是否是確定性的。使用 COLUMNPROPERTY 函數(shù)和 IsPrecise 屬性來確定包含架構(gòu)綁定的視圖中的確定性列是否是精確的。如果為 TRUE，則 COLUMNPROPERTY 會返回 1，如果為 FALSE，則返回 0，如果是無效的輸入（列不是確定性的），則返回 NULL.例如，SELECT COLUMNPROPERTY（Object_Id（'Vdiscount1'），'SumDiscountPrice'，'IsPrecise'） 返回的是 0，因為 SumDiscountPrice 列引用了表 Order Details 中的浮動列 Discount.而同一視圖中的列 SumPrice 既是確定性的又是精確的。
注意： 該 SELECT 語句所基于的視圖能夠在示例部分找到（視圖 1）。
其它要求
除“設(shè)計準則”、“使用 SET 選項以獲得一致的結(jié)果”和“使用確定性函數(shù)”部分中列出的要求之外，還必須符合以下要求。
基表要求
基表在創(chuàng)建時必須正確設(shè)置 SET 選項，否則就不能被包含架構(gòu)綁定的視圖引用。
表必須通過視圖定義中的兩部分名稱（所有者。表名）引用。
函數(shù)要求
用戶定義的函數(shù)必須使用 WITH SCHEMABINDING 選項創(chuàng)建。
用戶定義的函數(shù)必須通過兩部分名稱（所有者。函數(shù)）引用。
視圖要求
視圖必須使用 WITH SCHEMABINDING 選項創(chuàng)建。
視圖必須只引用同一數(shù)據(jù)庫中的基表，而不能引用其它視圖。
語法限制
對視圖定義的語法有幾個限制。視圖定義不能包含以下內(nèi)容：
COUNT（*）
ROWSET 函數(shù)
派生表
自聯(lián)接
DISTINCT
STDEV、VARIANCE、AVG
Float* 列、文本列、ntext 列、圖像列
子查詢
全文謂詞（CONTAIN、FREETEXT）
可空表達式的 SUM
MIN、MAX
TOP
OUTER 聯(lián)接
UNION
注意： 索引視圖可以包含浮動列，不過，此類列不能包含在群集索引關(guān)鍵字中。
GROUP BY 限制
如果未使用 GROUP BY，表達式不能在選擇列表中使用。
如果使用了 GROUP BY，則 VIEW 定義：
必須包含 COUNT_BIG（*）。
不得包含 HAVING、CUBE 或 ROLLUP.
這些限制只適用于索引視圖定義。查詢可以在其執(zhí)行計劃中使用索引視圖，即便該索引視圖并不符合這些 GROUP BY 限制。
索引要求
執(zhí)行 CREATE INDEX 語句的用戶必須是視圖所有者。
如果視圖定義中包含 GROUP BY 子句，唯一群集索引的關(guān)鍵字只能引用 GROUP BY 子句中指定的列。
示例
本部分的示例闡述索引視圖在兩種主要查詢（聚合和聯(lián)接）中的使用問題。同時還說明查詢優(yōu)化器在確定某個索引視圖是否可用時使用的條件。有關(guān)這些條件的完整列表，請參閱查詢優(yōu)化器如何使用索引視圖。
查詢基于 Northwind（SQL Server 2000 中提供的數(shù)據(jù)庫樣本）中的表，并可以寫入的方式執(zhí)行。創(chuàng)建視圖的前后，最好使用 SQL 查詢優(yōu)化器中的“顯示執(zhí)行計劃”工具來查看查詢優(yōu)化器選定的計劃。盡管示例中闡述了優(yōu)化器是如何選擇成本最低的執(zhí)行計劃的，但因為 Northwind 數(shù)據(jù)庫樣本太小，因此無法體現(xiàn)性能的提高。
以下查詢顯示如何從 Order Details 表中返回具有最大總折扣的五種產(chǎn)品的兩個方法。
查詢 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
查詢優(yōu)化器選定的執(zhí)行計劃包含：
對 Order Details 表的群集索引掃描，估計有 2，155 行。
哈希匹配/聚合運算符，該運算符基于 GROUP BY 列將選定的行放入哈希表，然后計算每行的 SUM 聚合。
基于 ORDER BY 子句的 TOP 5 排序運算符。
添加包括 Rebate 列所需聚合的索引視圖將更改查詢 1 的查詢執(zhí)行計劃。在數(shù)百萬行的大表上，查詢的性能也將明顯提高。
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）
第一個查詢的執(zhí)行計劃顯示 Vdiscount1 視圖由查詢優(yōu)化器使用。不過，由于該視圖不包含 SUM（UnitPrice*Quantity*Discount） 聚合，因此不會被第二個查詢使用?？梢詣?chuàng)建另一個可以同時滿足上述兩個查詢的索引視圖。
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）
有了該索引視圖，現(xiàn)在兩個查詢的查詢執(zhí)行計劃包含：
對 Vdiscount2 視圖的群集索引掃描，估計有 77 行
基于 ORDER BY 子句的 TOP 5 排序函數(shù)
查詢優(yōu)化器選擇該視圖是因為它提供了最低的執(zhí)行成本，盡管在查詢中并未引用該視圖。
查詢 3
查詢 3 類似于前幾個查詢，只是 ProductID 已被 OrderID 所取代，視圖定義中沒有包括該列。這違背了以下條件：查詢選擇列表中的所有表達式都必須能從未包括在視圖定義內(nèi)的表的視圖選擇列表中派生。
SELECT TOP 3 OrderID， SUM（UnitPrice*Quantity*Discount） OrderRebate
FROM dbo.[Order Details]
GROUP BY OrderID
ORDER BY OrderRebate desc
要求單獨的索引視圖來滿足該查詢?？梢詫?Vdiscount2 進行修改，使它包括 OrderID，但是所生成視圖的行數(shù)將與原表的行數(shù)相同，因此，提供的性能也不會高于使用基表所提供的性能。
查詢 4
該查詢可生成每個產(chǎn)品的平均價格。
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），不過，如果索引視圖中包括幾個聯(lián)合起來執(zhí)行復雜聚合的簡單聚合函數(shù)，即可用于執(zhí)行包含 AVG 的查詢。
視圖 3
該索引視圖包含執(zhí)行 AVG 函數(shù)所需的簡單聚合函數(shù)。在創(chuàng)建了視圖 3 后執(zhí)行查詢 4 時，執(zhí)行計劃會顯示正被使用的視圖。優(yōu)化器可以從視圖的簡單聚合列 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 相同，只不過包括一個附加搜索條件。即使該附加搜索條件只引用未包括在視圖定義內(nèi)的表中的列，視圖 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
查詢優(yōu)化器不能將視圖 3 用于該查詢。附加搜索條件 od.UnitPrice>10 包含視圖定義內(nèi)的表中的列，而該列卻不出現(xiàn)在 GROUP BY 列表中，搜索謂詞也不出現(xiàn)在視圖定義中。
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
相反，查詢優(yōu)化器可以將視圖 3 用于查詢 7，原因是新搜索條件 od.ProductID in （1，2，13，41） 中定義的列包括在視圖定義內(nèi)的 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 的聯(lián)接的查詢。該查詢符合以下條件：查詢 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 的變體。每個變體都違背了一個優(yōu)化器條件，因此與查詢 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
有關(guān)詳細信息
Microsoft SQL Server 2000 聯(lián)機圖書包含索引視圖的詳細信息。有關(guān)其它信息，請參閱以下資源：
Microsoft SQL Server Web 站點（英文）。
Microsoft SQL Server 開發(fā)人員中心（英文）。
SQL Server 雜志（英文）。
Microsoft.public.sqlserver.server 和 microsoft.public.sqlserver.datawarehouse 新聞組，其站點是：news://news.microsoft.com（英文）。
關(guān)于 SQL Server 的 Microsoft 正式課程。有關(guān)最新的課程信息，請參閱 Microsoft 培訓和服務(wù)站點（英文）。
來源：月光博客
