人气排行榜使用SQLServer2000索引视图提高性能
许多年来，Microsoft？SQLServer？一直都提供创建虚拟表（称为视图）的功能。在过去，这些视图主要有两种用途：
提供安全机制，将用户限制在一个或多个基表中的数据的某个子集。
提供一种机制，允许开发人员定制用户如何才能以逻辑方式查看存储在基表中的数据。
SQLServer2000已经扩展了SQLServer视图的功能，以提高系统性能。它可以在一个视图上创建唯一的群集索引和非群集索引，可以改进最复杂查询的数据访问性能。在SQLServer2000中，拥有唯一群集索引的视图被称为索引视图。
注意： 索引视图只是SQLServer2000企业版和SQLServer2000开发人员版的一个功能。
从数据库管理系统（DBMS）的观点来看，视图是数据（元数据）的说明。创建典型视图时，通过SELECT语句（定义一个显示为虚拟表的结果集）来定义元数据。当其它查询的FROM子句中引用了某个视图时，将从系统目录中检索该元数据，并对其进行扩展以代替该视图的引用。在视图扩展之后，查询优化器会为正在执行的查询编译单个执行计划。
如果是非索引视图，视图在运行时将被实体化。任何计算（如联接或聚合）都在为每个引用该视图的查询执行查询期间进行。（视图并不总需要被完全实体化。查询可以包含其它一些谓词、联接或聚合，以应用于该视图所引用的表和视图。）在视图上创建了唯一的群集索引之后，视图的结果集会立即被实体化并持续保存在数据库的物理存储空间中，以便节省这种操作所占用的大量资源。
在执行查询时，有两种方法可以使用索引视图。查询可直接引用索引视图，更重要的是，如果查询优化器确定视图能够替换为查询的部分或全部，而且这是低成本的查询计划，则可以选择索引视图。第二种情况是使用索引视图代替基础表及其普通索引。此时，不需要在查询中引用视图，查询优化器即可在执行查询期间使用该视图。这样，现有的应用程序无需更改即可从新建的索引视图中获益。
通过索引视图提高的性能
使用索引来提高查询性能并不是什么新观念，不过，索引视图还具有使用标准索引不能获得的其它性能优点。索引视图能够在以下方面提高查询性能：
能够预先计算聚合并将其存储在索引中，从而最大限度地减少在执行查询期间进行成本很高的计算。
能够预先联接表并存储生成的数据集。
能够存储联接或聚合的组合。
使用视图的辅助索引
视图的辅助性非群集索引可以提高其它查询性能。与表的辅助索引类似，视图的辅助索引也可以提供更多选项，以便查询优化器在编译过程中从中进行选择。例如，如果查询包括群集索引未涉及的列，优化器可以在计划中选择一个或多个辅助索引，从而避免对索引视图或基表进行费时的全局扫描。
由于索引需要不断维护，所以为架构添加索引会增加数据库的额外开销。因此应该认真考虑，找到索引和维护额外开销之间的平衡点。
使用索引视图的好处
实现索引视图之前，请先分析数据库的工作量。运用自己对查询以及各种工具（例如SQL分析器）的知识来鉴别使用索引视图可以获益的查询。如果经常进行聚合和联接，最好使用索引视图。
并非所有查询都会从索引视图中获益。与普通索引类似，如果未使用索引视图，就没有好处可言。在此情况下，不但不能提高性能，还会加大磁盘空间的占用、增加维护和优化的成本。但是，如果使用了索引视图，它们可以（成数量级地）明显地提高数据访问的性能。这是因为查询优化器使用存储在索引视图中的预先计算的结果，从而大大降低了执行查询的成本。
查询优化器只在查询的成本比较大时才考虑使用索引视图。这样可以避免在查询优化成本超出因使用索引视图而节省的成本时，试图使用各种索引视图。当查询成本低于1时，几乎不使用索引视图。
使用索引视图可以受益的应用包括：
联机分析处理（OLAP）库和源
从查询的类型和模式的角度来看，受益的应用可被归纳为包含以下内容的应用：
大表的联接和聚合
重复聚合相同或重叠的列集
针对相同关键字重复联接相同的表
相反，包含许多写入的联机事务处理（OLTP）系统或更新频繁的数据库，可能会因为要同时更新视图和根本基表而使维护成本增加，所以不能利用索引视图。
查询优化器如何使用索引视图
SQLServer查询优化器可自动确定何时可以将索引视图用于给定的查询执行中。查询中无需直接引用视图，优化器就可以将该视图用于查询执行计划。因此，无需对现有的应用程序本身进行任何更改，这些应用程序即可利用索引视图。唯一需要做的就是创建索引视图。
优化器的考虑因素
查询优化器会考虑几个条件来确定索引视图能涵盖部分查询还是整个查询。这些条件符合查询中的单个FROM子句并包含以下内容：
查询FROM子句中的表必须是索引视图FROM子句中的表的超集。
查询中的联接条件必须是视图中联接条件的超集。
查询中的聚合列必须是视图中的聚合列的子集。
查询选择列表中的所有表达式都必须源自于视图选择列表或源自于不包括在视图定义中的表。
查询搜索条件谓词必须是视图定义中搜索条件谓词的超集。视图搜索谓词中的每个合取项都必须以同样的形式出现在查询搜索谓词中。
查询搜索条件谓词中的所有列（属于视图定义中的表）都必须出现在下列一项或多项中：
视图定义中的同一个谓词。
视图选择列表（若没有GROUPBY列表）。
如果查询包含多个FROM子句（子查询、派生表、UNION），优化器可以选择多个索引视图来管理含有多个FROM子句的查询。
注意： 也存在例外情形，即优化器可能将两个FROM子句折叠成一个（将子查询折叠成联接或将派生表折叠成联接变体）。如果出现此类情况，索引视图替换可能会涵盖原查询中的多个FROM子句。
NOEXPAND选项强制查询优化器象对待包含群集索引的普通表一样对待视图。在此情况下，必须在FROM子句中直接引用索引视图。例如：
另外，用户可以在查询结束时通过使用EXPANDVIEWS选项，明确地将索引视图排除在考虑之外。例如：
如果使用该选项，查询优化器在评估低成本的方法（该方法涉及查询中引用的列）时将忽略所有视图索引。
为数据库系统找到适当的索引集是相当复杂的。尽管在设计普通索引时要考虑许多可能性，但将索引视图添加到架构会极大地增加设计和潜在结果的复杂性。例如，索引视图可用于：
查询中所引用表的任何子集。
查询中条件的任何子集（属于表的上述子集）
应同时设计表的索引和索引视图，以便从各个结构中获得最佳结果。由于索引和索引视图都可能对给定的查询有用，所以单独设计它们会导致多余的建议方案，以致存储和维护开销较高。在调整数据库的物理设计时，必须均衡考虑各种查询集的性能要求与数据库系统必须支持的更新操作。因此，为索引视图找到一种合理的物理设计是一项很具挑战性的任务，因而应该尽可能地使用“索引微调向导”。
如果存在许多索引视图可供查询优化器考虑用于特定查询，查询优化成本会显著增加。查询优化器可能考虑为查询中表的任意子集定义的所有索引视图。拒绝每一个视图之前，必须对它进行语法分析，然后研究其是否可能成为潜在的替换体。这可能需要一些时间，尤其是在有数百个此类的视图用于给定的查询时。
视图必须符合几项要求，您才能为其创建唯一的群集索引。在设计阶段，请考虑以下要求：
视图以及视图中引用的所有表都必须在同一数据库中，并具有同一个所有者。
索引视图无需包含要供优化器使用的查询中引用的所有表。
必须先为视图创建唯一群集索引，然后才可以创建其它索引。
视图必须使用架构绑定创建，视图中引用的任何用户定义的函数必须使用SCHEMABINDING选项创建。
另外，还要求有一定的磁盘空间来存放由索引视图定义的数据。
设计索引视图时，请考虑以下准则：
设计的索引视图必须能用于多个查询或多个计算。
例如，包含某列的SUM和某列的COUNT_BIG的索引视图可用于包含函数SUM、COUNT、COUNT_BIG或AVG的查询。由于只需检索视图中的少数几行，而不是基表中的所有行，且执行AVG函数要求的部分计算已经完成，所以查询将比较快。
通过使用最少的列数和尽可能少的字节数，优化器在查找行数据时可获得最高的效率。相反，如果定义了大的群集索引关键字，则为视图定义的任何辅助性非群集索引都将明显增大，这是因为非群集索引项除包含索引定义的列之外，还将包含群集关键字。
考虑生成的索引视图的大小。
在单纯的聚合情况下，如果索引视图的大小类似于原表的大小，使用索引视图可能无法明显提高任何性能。
设计多个较小的索引视图来加快部分进程的速度。
有时可能无法设计出能满足整个查询需要的索引视图。此时即可考虑创建这样一些索引视图，每个索引视图执行一部分查询。
经常执行的查询会聚合一个数据库中的数据，再聚合另一个数据库中的数据，然后联接结果。由于索引视图不能引用多个数据库中的表，所以您不能设计一个视图来执行整个进程。不过，可以为要进行聚合的每个数据库创建索引视图。如果优化器能够将索引视图与现有查询相匹配，至少聚合处理将会因为不必记录现有查询而提高速度。尽管联接处理不会加快，整个查询的速度却因使用了存储在索引视图中的聚合而加快。
经常执行的查询会聚合多个表中的数据，然后使用UNION来将结果结合起来。UNION不允许在索引视图中使用。您可以设计一些视图来执行每个单独的聚合运算。然后优化器可以选择索引视图来加快查询的速度，而无需记录查询。尽管UNION处理没有改进，单个聚合进程却得以改进。
使用“索引微调向导”
“索引微调向导”除建议使用基表的索引之外，还建议使用索引视图。使用该向导可提高管理员确定索引和索引视图相结合的能力，从而优化针对数据库执行的典型混合查询的性能。
由于“索引微调向导”强制使用所有必需的SET选项（以确保结果集的正确性），其索引视图将会成功创建。不过，如果您的应用程序的选项没有按照要求设置，可能无法利用这些视图。对那些参与索引视图定义的表执行的插入、更新或删除操作可能会失败。
SQLServer自动维护索引视图，这与维护任何其它索引的情况类似。对于普通索引而言，每个索引都直接连接到单个表。通过对基础表执行每个INSERT、UPDATE或DELETE操作，索引相应地进行了更新，以便使存储在该索引中的值始终与表一致。
索引视图的维护与此类似。不过，如果视图引用了多个表，则对这些表中的任何一个进行更新都需要更新索引视图。与普通索引不同的是，对任何一个参与的表执行一次行插入操作都可能导致在索引视图中进行多次行插入操作。更新和删除操作的情况也是如此。因此，较之于维护表的索引，维护索引视图的代价更为高昂。
在SQLServer2000中，某些视图可以更新。如果某个视图可以更新，则使用INSERT、UPDATE和DELETE语句可通过该视图直接修改根本基表。为某个视图创建索引并不会妨碍该视图的更新。有关可更新视图的详细信息，请参阅关于SQLServer2000的“SQLServer联机图书”中的“通过视图修改数据（英文）”。
维护成本的考虑因素
设计索引视图时应该考虑以下几点：
数据库中需要有一个额外的存储空间用于索引视图。索引视图的结果集以类似于典型表存储空间的方式物理保存在数据库中。
SQLServer自动维护视图。因此，对定义视图所据的基表的任何更改都可能引起视图索引的一处或多处更改，从而导致维护开销的增加。
一个视图获得的净性能提高就是视图提供的查询执行节约总计与存储和维护该视图耗费的成本之间的差。
估计视图将占用的所需存储空间要相对简单一些。用SQL查询分析器的“显示估计的执行计划”工具求视图定义中SELECT语句的值。该工具将得出查询返回的行数和行大小的近似值。将这两个值相乘，即可估计出视图的可能大小。不过这只是一个近似值。视图索引的实际大小只能通过创建视图索引来精确得出。
从SQLServer执行的自动维护考虑因素的观点出发，“显示估计的执行计划”的功能可能会对此开销的影响有所了解。如果用SQL查询分析器评估修改视图的语句（针对视图的UPDATE语句、针对基表的INSERT语句），SHOWPLAN将包括该语句的维护操作。同时考虑此成本和此操作将在生产环境中发生的次数，可以指示视图维护的可能成本。
通常建议对视图或基表进行的任何修改和更新都应该尽可能地成批执行，而不要单独进行。这样可以减少视图维护的某些开销。
创建索引视图所需的步骤与视图的成功实现密不可分。
确保将在视图中引用的所有现有表的SET选项都正确。
创建任何新表和视图之前，确保会话的SET选项已正确设置。
确保视图定义是确定的。
使用WITHSCHEMABINDING选项创建视图。
创建视图的唯一群集索引。
使用SET选项以获得一致的结果
如果在执行查询时启用不同的SET选项，则在SQLServer中对同一个表达式求值会产生不同的结果。例如，将SET选项CONCAT_NULL_YIELDS_NULL设置为ON之后，表达式'abc'NULL返回的值是NULL.而将CONCAT_NULL_YIEDS_NULL设置为OFF之后，该表达式得出的结果却是'abc'.索引视图要求多个SET选项的值都固定，以确保这些视图能够得到正确维护并返回一致的结果。
只要出现以下情况，就必须将下表中的SET选项设置为要求的值列中所示的值：
对索引视图中引用的任何表执行了任何INSERT、UPDATE或DELETE操作。
查询优化器使用索引视图来生成查询计划。
如果使用的是OLEDB或ODBC服务器连接，唯一必须修改的值是ARITHABORT的设置。所有DBLIB值都必须使用sp_configure在服务器级上正确设置或使用SET命令从应用程序正确设置。有关SET选项的详细信息，请参阅关于SQLServer2000的“SQLServer联机图书”中的“使用SQLServer中的选项（英文）”。
索引视图的定义必须是确定性的。如果选择列表中的所有表达式以及WHERE和GROUPBY子句都是确定性的，则视图就是确定性的。只要用特定的一组输入值对确定性表达式进行求值，一定会返回同一个结果。只有确定性函数可以加入确定性表达式。例如，DATEADD是确定性函数，因为将任何给定的一组变量值赋予它的三个参数进行求值，返回的总是同一个结果。而GETDATE则不是确定性函数，因为始终用同一个变量调用它，而它每次执行后返回的值都不相同。有关详细信息，请参阅关于SQLServer2000的“SQLServer联机图书”中的“确定性和非确定性函数”。
即便某个表达式是确定性的，但如果其中包含浮动表达式，确切的结果就可能取决于处理器的体系结构或微代码的版本。要确保SQLServer2000中数据的完整性，此类表达式只能加入索引视图的非关键列。不包含浮动表达式的确定性表达式被称为精确的表达式。只有精确的确定性表达式可以加入索引视图的关键列和WHERE或GROUPBY子句。
使用COLUMNPROPERTY函数和IsDeterministic属性来确定视图列是否是确定性的。使用COLUMNPROPERTY函数和IsPrecise属性来确定包含架构绑定的视图中的确定性列是否是精确的。如果为TRUE，则COLUMNPROPERTY会返回1，如果为FALSE，则返回0，如果是无效的输入（列不是确定性的），则返回NULL.例如，SELECTCOLUMNPROPERTY（Object_Id（'Vdiscount1'），'SumDiscountPrice'，'IsPrecise'）返回的是0，因为SumDiscountPrice列引用了表OrderDetails中的浮动列Discount.而同一视图中的列SumPrice既是确定性的又是精确的。
注意： 该SELECT语句所基于的视图能够在示例部分找到（视图1）。
除“设计准则”、“使用SET选项以获得一致的结果”和“使用确定性函数”部分中列出的要求之外，还必须符合以下要求。
基表在创建时必须正确设置SET选项，否则就不能被包含架构绑定的视图引用。
表必须通过视图定义中的两部分名称（所有者。表名）引用。
用户定义的函数必须使用WITHSCHEMABINDING选项创建。
用户定义的函数必须通过两部分名称（所有者。函数）引用。
视图必须使用WITHSCHEMABINDING选项创建。
视图必须只引用同一数据库中的基表，而不能引用其它视图。
对视图定义的语法有几个限制。视图定义不能包含以下内容：
Float*列、文本列、ntext列、图像列
注意： 索引视图可以包含浮动列，不过，此类列不能包含在群集索引关键字中。
如果未使用GROUPBY，表达式不能在选择列表中使用。
如果使用了GROUPBY，则VIEW定义：
这些限制只适用于索引视图定义。查询可以在其执行计划中使用索引视图，即便该索引视图并不符合这些GROUPBY限制。
执行CREATEINDEX语句的用户必须是视图所有者。
如果视图定义中包含GROUPBY子句，唯一群集索引的关键字只能引用GROUPBY子句中指定的列。
本部分的示例阐述索引视图在两种主要查询（聚合和联接）中的使用问题。同时还说明查询优化器在确定某个索引视图是否可用时使用的条件。有关这些条件的完整列表，请参阅查询优化器如何使用索引视图。
查询基于Northwind（SQLServer2000中提供的数据库样本）中的表，并可以写入的方式执行。创建视图的前后，最好使用SQL查询优化器中的“显示执行计划”工具来查看查询优化器选定的计划。尽管示例中阐述了优化器是如何选择成本最低的执行计划的，但因为Northwind数据库样本太小，因此无法体现性能的提高。
以下查询显示如何从OrderDetails表中返回具有最大总折扣的五种产品的两个方法。
查询优化器选定的执行计划包含：
对OrderDetails表的群集索引扫描，估计有2，155行。
哈希匹配/聚合运算符，该运算符基于GROUPBY列将选定的行放入哈希表，然后计算每行的SUM聚合。
基于ORDERBY子句的TOP5排序运算符。
添加包括Rebate列所需聚合的索引视图将更改查询1的查询执行计划。在数百万行的大表上，查询的性能也将明显提高。
第一个查询的执行计划显示Vdiscount1视图由查询优化器使用。不过，由于该视图不包含SUM（UnitPrice*Quantity*Discount）聚合，因此不会被第二个查询使用。可以创建另一个可以同时满足上述两个查询的索引视图。
有了该索引视图，现在两个查询的查询执行计划包含：
对Vdiscount2视图的群集索引扫描，估计有77行
基于ORDERBY子句的TOP5排序函数
查询优化器选择该视图是因为它提供了最低的执行成本，尽管在查询中并未引用该视图。
查询3类似于前几个查询，只是ProductID已被OrderID所取代，视图定义中没有包括该列。这违背了以下条件：查询选择列表中的所有表达式都必须能从未包括在视图定义内的表的视图选择列表中派生。
要求单独的索引视图来满足该查询。可以对Vdiscount2进行修改，使它包括OrderID，但是所生成视图的行数将与原表的行数相同，因此，提供的性能也不会高于使用基表所提供的性能。
该查询可生成每个产品的平均价格。
索引视图的定义中不能包括复杂的聚合（例如，STDEV、VARIANCE、AVG），不过，如果索引视图中包括几个联合起来执行复杂聚合的简单聚合函数，即可用于执行包含AVG的查询。
该索引视图包含执行AVG函数所需的简单聚合函数。在创建了视图3后执行查询4时，执行计划会显示正被使用的视图。优化器可以从视图的简单聚合列Price和Count中导出AVG表达式。
该查询与查询4相同，只不过包括一个附加搜索条件。即使该附加搜索条件只引用未包括在视图定义内的表中的列，视图3也将用于该查询。
查询优化器不能将视图3用于该查询。附加搜索条件od.UnitPrice>10包含视图定义内的表中的列，而该列却不出现在GROUPBY列表中，搜索谓词也不出现在视图定义中。
相反，查询优化器可以将视图3用于查询7，原因是新搜索条件od.ProductIDin（1，2，13，41）中定义的列包括在视图定义内的GROUPBY子句中。
该视图在视图定义中包括了列od.Discount，可以满足查询6的条件。
视图4的同一个索引还将用于一个添加了与表Orders的联接的查询。该查询符合以下条件：查询FROM子句中列出的表是索引视图的FROM子句中表的超集。
最后两个查询是查询8的变体。每个变体都违背了一个优化器条件，因此与查询8不同，不能使用视图4.
由于视图定义中的UnitPrice>10与查询中的UnitPrice>25之间的WHERE子句不匹配，所以Q8a不能使用索引视图。查询搜索条件谓词必须是视图定义中搜索条件谓词的超集。
注意，表Orders没有参与索引视图V4的定义。尽管如此，在该表中添加谓词将禁止使用索引视图，原因是添加的谓词可能会消除聚合中的其它行（如查询8b中所示）。
MicrosoftSQLServer2000联机图书包含索引视图的详细信息。有关其它信息，请参阅以下资源：
MicrosoftSQLServer开发人员中心（英文）。
Microsoft.public.sqlserver.server和microsoft.public.sqlserver.datawarehouse新闻组，其站点是：news://news.microsoft.com（英文）。
关于SQLServer的Microsoft正式课程。有关最新的课程信息，请参阅Microsoft培训和服务站点（英文）。
扫描二维码推送至手机访问。
3浏览自媒体运营与推广
2浏览网站结构优化
2浏览外部链接建设
2浏览自媒体运营与推广
相关标签： SQLServer、
本文地址：https://www.badfl.com/article/8a04b1a8efb7c75b2b14.html
<a href="https://www.badfl.com/" target="_blank">自动秒收录</a>