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

 

什么是索引视图？

许多年来，Microsoft SQL Server" 一直都提供创建虚拟表（称为视图）的功能。在过去，这些视图主要有两种用途：

1. 提供安全机制，将用户限制在一个或多个基表中的数据的某个子集。
2. 提供一种机制，允许开发人员定制用户如何才能以逻辑方式查看存储在基表中的数据。

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 将包括该语句的维护操作。同时考虑此成本和此操作将在生产环境中发生的次数，可以指示视图维护的可能成本。

通常建议对视图或基表进行的任何修改和更新都应该尽可能地成批执行，而不要单独进行。这样可以减少视图维护的某些开销。