使用SQL Server 2000索引视图提高性能
使用索引视图可以受益的应用包括：
◆决定支持工作量
◆数据集市
◆联机剖析处理 (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。
应同时设计表的索引和索引视图，以便从各个结构中获得最佳结果。由于索引和索引视图都可能对给定的查询有用，所以单独设计它们会导致多余的建议方案，以致存储和维护开销较高。在调整数据库的物理设计时，必需均衡考虑各种查询集的性能要求与数据库系统必须支持的更新操作。因此，为索引视图找到一种合理的物理设计是一项很具挑战性的任务，因此应该尽可能地使用“索引微调向导”。
要是存在许多索引视图可供查询优化器考虑用于特定查