如果查詢包含多個 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 選項創建。
另外，還要求有一定的磁盤空間來存放由索引視圖定義的數據。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
