使用SQL Server 2000索引视图提高性能

使用索引视图的好处

实现索引视图之前，请先分析数据库的工作量。运用自己对查询以及各种工具（例如 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 选项创建。 另外，还要求有一定的磁盘空间来存放由索引视图定义的数据。