设计方针
设计索引视图时考虑这些指导方针：
• 设计可供几个查询或多项操作使用的索引视图。
例如，包含列的 SUM 和 COUNT_BIG 的索引视图可供包含函数 SUM、COUNT、COUNT_BIG 或 AVG 的查询使用。查询的速度会更快，因为只需对视图中少量的行进行检索，而不必检索基表中所有的行，而且执行 AVG 函数所需的一部分计算已经完成。
• 使索引键保持简洁。
通过在索引键中尽可能使用最少的列和字节，可对索引视图的列实现更高效的访问，因为索引视图的列更窄，键比较的速度较更宽的键快一些。另外，在索引视图上定义的每个非聚集索引中，聚集索引键都被用作行定位器。较大的索引键的成本随视图上非聚集索引的数量成比例增长。
• 考虑最终索引视图的大小。
对于纯聚合，如果索引视图的大小与原始表的大小不相上下，可能就不会实现巨大的性能改善。
• 设计多个较小的索引视图来局部加速过程。
可能无法总对整个查询设计一个索引视图。如要怎么做，考虑创建若干个索引视图，各执行部分查询。
考虑这几个例子：
• 经常执行的查询会在一个数据库中聚合数据，并在另一个数据库中聚合数据，然后再联接结果。因为索引视图无法从多个数据库引用表，所以用户不能设计一个视图来执行整个过程。但是，可以在每个数据库中创建一个索引视图来进行各个数据库的聚合操作。如果优化器可匹配索引视图和现有的查询，那么至少聚合处理的速度会更快，同时不必对现有的查询进行重新编码。虽然联接处理不会加快，但整个查询将变快，因为其使用存储在索引视图中的聚合。
• 经常执行的查询聚合来自几个表的数据，然后使用 UNION 合并结果。索引视图不支持 UNION。可设计若干个视图来执行每个聚合操作。而后，优化器可选择索引视图来加快查询，而不必对查询进行重新编码。虽然未改进 UNION 处理，但改善了各个聚合过程。
有能帮助选择索引视图的工具吗？
数据库优化顾问 (DTA3) 是 SQL Server 2005 的一项功能，可帮助管理员优化物理数据库设计。除了建议使用基表上的索引以及表和索引分区策略外，DTA 还推荐使用索引视图。使用 DTA 可加强管理员确定索引、索引视图和分区策略（可优化对数据库执行的查询的典型组合的性能）的组合的能力。DTA 会向用户推荐广泛的索引视图。其中包括运用 SQL Server 2005 的索引视图的新功能（在“SQL Server 2005 的索引视图有哪些新增功能？”一节有所描述）的索引视图。DTA 并没有排除让数据库管理在设计物理存储结构时做出恰当判断的需要。但是，它可以简化物理数据库的设计过程。DTA 通过推荐一组假定的索引，索引视图和分区结果，与基于成本的查询优化器协同工作。DTA 使用优化器来估计当使用和不使用这些结构时的工作负荷成本，并推荐可提供较低的总成本的结构。
因为数据库优化顾问强制执行所有必须的 SET 选项（确保结果集正确无误），所以将成功完成索引视图的创建。然而，如果未能按要求设置选项，用户的应用程序可能无法运用这些视图。如果未按要求指定 SET 选项，对加入索引视图定义的表执行的插入、更新或删除操作就有可能失败。
更新数据时索引视图会有什么变化？
与其他任何索引一样，当基表数据变化时，SQL Server 会自动维护索引视图。对于一般索引，每个索引都直接与一个表相关联。随着在基础表上执行每一项 INSERT、UPDATE 或 DELETE 操作，索引将被相应地更新，从而使保存在索引中的值总是与表保持一致。
索引视图也得到相同的维护；但是，如果视图引用了若干个表，那么更新任何一个表都需要更新索引视图。不同于一般索引，在任何参与的表中插入一行都可能导致索引视图中发生多行更改。这是因为所插入的行可能与另一个表的多个行相联接。更新和删除行的情况也一样。因此，索引视图的维护成本可能比维护表上的索引更高。相反，维护具有高选择性条件的索引视图的成本可能要比维护表上的索引低得多，因为多数对视图所引用的基表的插入、删除和更新操作不会影响视图。不用访问其他数据库数据就可为索引视图筛选掉这些操作。
在 SQL Server 中，可更新某些视图。当某个视图可更新时，将使用 INSERT、UPDATE 和 DELETE 语句通过视图直接修改底层基表。在视图上创建索引不会阻止视图的更新。索引视图的更新确实会导致视图下基表的更新。这些更新会作为索引视图维护的一部分自动传播回索引视图。有关可更新的视图的详细信息，参阅面向 SQL Server 2005 的 SQL Server 联机丛书中的“通过视图修改数据”。
维护成本注意事项
设计索引视图时应考虑下面这几点：
• 索引视图的数据库需要附加存储。索引视图的结果集在物理上通过与典型表存储相似的方式保留在数据库中。
• SQL Server 会自动维护视图；因此，对定义了视图的基表进行的任何更改都可能引发对索引视图进行一项或多项更改。所以，将产生额外的维护开销。
视图所获得的净性能提升为其所实现的总查询执行成本节约与存储和维护成本的差值。
比较容易获得接近于视图所需的存储。通过 SQL Server Management Studio 工具——显示预计的执行计划，评估视图定义所封装的 SELECT 语句。该工具将生成查询所返回的行数和行大小的近似值。通过将这两个值相乘，就可以获得接近于可能的视图大小；但是，只是近似。只有在视图定义中执行查询或在视图上创建索引，才能确定视图上索引的实际大小。
从 SQL Server 所执行的自动维护注意事项的角度来看，显示预计的执行计划功能可能会让用户在一定程度上了解这一开销的影响。如果通过 SQL Server Management Studio 评估修改视图的语句（视图上的 UPDATE、基表中的 INSERT），对该语句显示的执行计划将包括该语句的维护操作。如果就该操作在生产环境中所要执行的次数考虑该成本，那么可能会产生视图维护成本。
通常建议尽可能对视图或其底下的基表成批（而非单独）执行任何修改或更新操作。这样就会降低视图维护开销。
