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

查询搜索条件谓词中的所有列（属于视图定义中的表）都必须出现在下列一项或多项中：

● 视图定义中的同一个谓词。

● 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。

应同时设计表的索引和索引视图，以便从各个结构中获得最佳结果。由于索引和索引视图都可能对给定的查询有用，所以单独设计它们会导致多余的建议方案，以致存储和维护开销较高。在调整数据库的物理设计时，必须均衡考虑各种查询集的性能要求与数据库系统必须支持的更新操作。因此，为索引视图找到一种合理的物理设计是一项很具挑战性的任务，因而应该尽可能地使用“索引微调向导”。

假如存在许多索引视图可供查询优化器考虑用于特定查询，查询优化成本会显著增加。查询优化器可能考虑为查询中表的任意子集定义的所有索引视图。拒绝每一个视图之前，必须对它进行语法分析，然后研究其是否可能成为潜在的替换体。这可能需要一些时间，尤其是在有数百个此类的视图用于给定的查询时。
共4页: 上一页 [1] [2] 3 [4] 下一页

评论加载中…