用SQLServer2000索引视图提高性能(下)

server|sqlserver|视图|索引|性能

使用“索引微调向导”

“索引微调向导”除建议使用基表的索引之外,还建议使用索引视图。使用该向导可提高管理员确定索引和索引视图相结合的能力,从而优化针对数据库执行的典型混合查询的性能。

由于“索引微调向导”强制使用所有必需的 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 将包括该语句的维护操作。同时考虑此成本和此操作将在生产环境中发生的次数,可以指示视图维护的可能成本。

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

创建索引视图

创建索引视图所需的步骤与视图的成功实现密不可分。

确保将在视图中引用的所有现有表的 SET 选项都正确。
创建任何新表和视图之前,确保会话的 SET 选项已正确设置。
确保视图定义是确定的。
使用 WITH SCHEMABINDING 选项创建视图。
创建视图的唯一群集索引。

使用 SET 选项以获得一致的结果

如果在执行查询时启用不同的 SET 选项,则在 SQL Server 中对同一个表达式求值会产生不同的结果。例如,将 SET 选项 CONCAT_NULL_YIELDS_NULL 设置为 ON 之后,表达式 'abc' + NULL 返回的值是 NULL。而将 CONCAT_NULL_YIEDS_NULL 设置为 OFF 之后,该表达式得出的结果却是 'abc'。索引视图要求多个 SET 选项的值都固定,以确保这些视图能够得到正确维护并返回一致的结果。

只要出现以下情况,就必须将下表中的 SET 选项设置为要求的值列中所示的值:

创建了索引视图。
对索引视图中引用的任何表执行了任何 INSERT、UPDATE 或 DELETE 操作。
查询优化器使用索引视图来生成查询计划。
SET
选项 要求
的值 默认
服务器
的值 OLE DB

ODBC 的值 DB LIB
的值
ANSI_NULLS ON OFF ON OFF
ANSI_PADDING ON ON ON OFF
ANSI_WARNING ON OFF ON OFF
ARITHABORT ON OFF OFF OFF
CONCAT_NULL_YIELDS_NULL ON OFF ON OFF
NUMERIC_ROUNDABORT OFF OFF OFF OFF
QUOTED_IDENTIFIER ON OFF ON OFF

如果使用的是 OLE DB 或 ODBC 服务器连接,唯一必须修改的值是 ARITHABORT 的设置。所有 DB LIB 值都必须使用 sp_configure 在服务器级上正确设置或使用 SET 命令从应用程序正确设置。有关 SET 选项的详细信息,请参阅关于 SQL Server 2000 的“SQL Server 联机图书”中的“使用 SQL Server 中的选项(英文)”。

使用确定性函数

索引视图的定义必须是确定性的。如果选择列表中的所有表达式以及 WHERE 和 GROUP BY 子句都是确定性的,则视图就是确定性的。只要用特定的一组输入值对确定性表达式进行求值,一定会返回同一个结果。只有确定性函数可以加入确定性表达式。例如,DATEADD 是确定性函数,因为将任何给定的一组变量值赋予它的三个参数进行求值,返回的总是同一个结果。而 GETDATE 则不是确定性函数,因为始终用同一个变量调用它,而它每次执行后返回的值都不相同。有关详细信息,请参阅关于 SQL Server 2000 的“SQL Server 联机图书”中的“确定性和非确定性函数”。

即便某个表达式是确定性的,但如果其中包含浮动表达式,确切的结果就可能取决于处理器的体系结构或微代码的版本。要确保 SQL Server 2000 中数据的完整性,此类表达式只能加入索引视图的非关键列。不包含浮动表达式的确定性表达式被称为精确的表达式。只有精确的确定性表达式可以加入索引视图的关键列和 WHERE 或 GROUP BY 子句。

使用 COLUMNPROPERTY 函数和 IsDeterministic 属性来确定视图列是否是确定性的。使用 COLUMNPROPERTY 函数和 IsPrecise 属性来确定包含架构绑定的视图中的确定性列是否是精确的。如果为 TRUE,则 COLUMNPROPERTY 会返回 1,如果为 FALSE,则返回 0,如果是无效的输入(列不是确定性的),则返回 NULL。例如,SELECT COLUMNPROPERTY(Object_Id('Vdiscount1'),'SumDiscountPrice','IsPrecise') 返回的是 0,因为 SumDiscountPrice 列引用了表 Order Details 中的浮动列 Discount。而同一视图中的列 SumPrice 既是确定性的又是精确的。

注意:   该 SELECT 语句所基于的视图能够在示例部分找到(视图 1)。

其它要求

除“设计准则”、“使用 SET 选项以获得一致的结果”和“使用确定性函数”部分中列出的要求之外,还必须符合以下要求。

基表要求

基表在创建时必须正确设置 SET 选项,否则就不能被包含架构绑定的视图引用。
表必须通过视图定义中的两部分名称(所有者.表名)引用。
函数要求

用户定义的函数必须使用 WITH SCHEMABINDING 选项创建。
用户定义的函数必须通过两部分名称(所有者.函数)引用。
视图要求

视图必须使用 WITH SCHEMABINDING 选项创建。
视图必须只引用同一数据库中的基表,而不能引用其它视图。
语法限制

对视图定义的语法有几个限制。视图定义不能包含以下内容:

COUNT(*)
ROWSET 函数
派生表
自联接
DISTINCT
STDEV、VARIANCE、AVG
Float* 列、文本列、ntext 列、图像列
子查询
全文谓词(CONTAIN、FREETEXT)
可空表达式的 SUM
MIN、MAX
TOP
OUTER 联接
UNION
注意:   索引视图可以包含浮动列,不过,此类列不能包含在群集索引关键字中。

GROUP BY 限制

如果未使用 GROUP BY,表达式不能在选择列表中使用。

如果使用了 GROUP BY,则 VIEW 定义:

必须包含 COUNT_BIG(*)。
不得包含 HAVING、CUBE 或 ROLLUP。
这些限制只适用于索引视图定义。查询可以在其执行计划中使用索引视图,即便该索引视图并不符合这些 GROUP BY 限制。

索引要求

执行 CREATE INDEX 语句的用户必须是视图所有者。
如果视图定义中包含 GROUP BY 子句,唯一群集索引的关键字只能引用 GROUP BY 子句中指定的列。

示例

本部分的示例阐述索引视图在两种主要查询(聚合和联接)中的使用问题。同时还说明查询优化器在确定某个索引视图是否可用时使用的条件。有关这些条件的完整列表,请参阅查询优化器如何使用索引视图。

查询基于 Northwind(SQL Server 2000 中提供的数据库样本)中的表,并可以写入的方式执行。创建视图的前后,最好使用 SQL 查询优化器中的“显示执行计划”工具来查看查询优化器选定的计划。尽管示例中阐述了优化器是如何选择成本最低的执行计划的,但因为 Northwind 数据库样本太小,因此无法体现性能的提高。

以下查询显示如何从 Order Details 表中返回具有最大总折扣的五种产品的两个方法。

查询 1

SELECT TOP 5 ProductID, SUM(UnitPrice*Quantity) -
SUM(UnitPrice*Quantity*(1.00-Discount))AS Rebate
FROM [Order Details]
GROUP BY ProductID
ORDER BY Rebate DESC

查询 2

SELECT TOP 5 ProductID, SUM(UnitPrice*Quantity*Discount)AS Rebate
FROM [Order Details]
GROUP BY ProductID
ORDER BY Rebate DESC

查询优化器选定的执行计划包含:

对 Order Details 表的群集索引扫描,估计有 2,155 行。
哈希匹配/聚合运算符,该运算符基于 GROUP BY 列将选定的行放入哈希表,然后计算每行的 SUM 聚合。
基于 ORDER BY 子句的 TOP 5 排序运算符。
视图 1

添加包括 Rebate 列所需聚合的索引视图将更改查询 1 的查询执行计划。在数百万行的大表上,查询的性能也将明显提高。

CREATE VIEW Vdiscount1 WITH SCHEMABINDING
AS
SELECT SUM(UnitPrice*Quantity)AS SumPrice,
SUM(UnitPrice*Quantity*(1.00-Discount))
AS SumDiscountPrice, COUNT_BIG(*) AS Count, ProductID
FROM dbo.[Order Details]
GROUP BY ProductID
   GO
CREATE UNIQUE CLUSTERED INDEX VDiscountInd ON Vdiscount1 (ProductID)

第一个查询的执行计划显示 Vdiscount1 视图由查询优化器使用。不过,由于该视图不包含 SUM(UnitPrice*Quantity*Discount) 聚合,因此不会被第二个查询使用。可以创建另一个可以同时满足上述两个查询的索引视图。

视图 2

CREATE VIEW Vdiscount2 WITH SCHEMABINDING
AS
SELECT SUM(UnitPrice*Quantity)AS SumPrice,
SUM(UnitPrice*Quantity*(1.00-Discount))AS SumDiscountPrice,
SUM(UnitPrice*Quantity*Discount)AS SumDiscountPrice2, COUNT_BIG(*)
AS Count, ProductID
FROM dbo.[Order Details]
GROUP BY ProductID
GO
CREATE UNIQUE CLUSTERED INDEX VDiscountInd ON Vdiscount2 (ProductID)

有了该索引视图,现在两个查询的查询执行计划包含:

对 Vdiscount2 视图的群集索引扫描,估计有 77 行
基于 ORDER BY 子句的 TOP 5 排序函数
查询优化器选择该视图是因为它提供了最低的执行成本,尽管在查询中并未引用该视图。

查询 3

查询 3 类似于前几个查询,只是 ProductID 已被 OrderID 所取代,视图定义中没有包括该列。这违背了以下条件:查询选择列表中的所有表达式都必须能从未包括在视图定义内的表的视图选择列表中派生。

SELECT TOP 3 OrderID, SUM(UnitPrice*Quantity*Discount) OrderRebate
FROM dbo.[Order Details]
GROUP BY OrderID
ORDER BY OrderRebate desc

要求单独的索引视图来满足该查询。可以对 Vdiscount2 进行修改,使它包括 OrderID,但是所生成视图的行数将与原表的行数相同,因此,提供的性能也不会高于使用基表所提供的性能。

查询 4

该查询可生成每个产品的平均价格。

SELECT ProductName, od.ProductID,
AVG(od.UnitPrice*(1.00-Discount)) AS AvgPrice, SUM(od.Quantity) AS Units
FROM [Order Details] od, Products p
WHERE od.ProductID=p.ProductID
GROUP BY ProductName, od.ProductID

索引视图的定义中不能包括复杂的聚合(例如,STDEV、VARIANCE、AVG),不过,如果索引视图中包括几个联合起来执行复杂聚合的简单聚合函数,即可用于执行包含 AVG 的查询。

视图 3

该索引视图包含执行 AVG 函数所需的简单聚合函数。在创建了视图 3 后执行查询 4 时,执行计划会显示正被使用的视图。优化器可以从视图的简单聚合列 Price 和 Count 中导出 AVG 表达式。

CREATE VIEW View3 WITH SCHEMABINDING
AS
SELECT ProductID, SUM(UnitPrice*(1.00-Discount))AS Price,
COUNT_BIG(*)AS Count, SUM(Quantity)AS Units
FROM dbo.[Order Details]
GROUP BY ProductID
Go
CREATE UNIQUE CLUSTERED INDEX iv3 ON View3 (ProductID)

查询 5

该查询与查询 4 相同,只不过包括一个附加搜索条件。即使该附加搜索条件只引用未包括在视图定义内的表中的列,视图 3 也将用于该查询。

SELECT ProductName, od.ProductID, AVG(od.UnitPrice*(1.00-Discount))
AS AvgPrice, SUM(od.Quantity)AS Units
FROM [Order Details] AS od, Products AS p
WHERE od.ProductID=p.ProductID
AND p.ProductName like '%Tofu%'
GROUP BY ProductName, od.ProductID

查询 6

查询优化器不能将视图 3 用于该查询。附加搜索条件 od.UnitPrice>10 包含视图定义内的表中的列,而该列却不出现在 GROUP BY 列表中,搜索谓词也不出现在视图定义中。

SELECT ProductName, od.ProductID, AVG(od.UnitPrice*(1.00-Discount))
AS AvgPrice, SUM(od.Quantity) AS Units
FROM [Order Details] od, Products p
WHERE od.ProductID = p.ProductID
AND od.UnitPrice > 10
GROUP BY ProductName, od.ProductID

查询 7

相反,查询优化器可以将视图 3 用于查询 7,原因是新搜索条件 od.ProductID in (1,2,13,41) 中定义的列包括在视图定义内的 GROUP BY 子句中。

SELECT ProductName, od.ProductID, AVG(od.UnitPrice*(1.00-Discount))
AS AvgPrice, SUM(od.Quantity) AS Units
FROM [Order Details] AS od, Products AS p
WHERE od.ProductID = p.ProductID
AND od.ProductID in (1,2,13,41)
GROUP BY ProductName, od.ProductID

视图 4

该视图在视图定义中包括了列 od.Discount,可以满足查询 6 的条件。

CREATE VIEW View4 WITH SCHEMABINDING
AS
SELECT ProductName, od.ProductID, SUM(od.UnitPrice*(1.00-Discount))
AS AvgPrice, SUM(od.Quantity) AS Units, COUNT_BIG(*) AS Count
FROM dbo.[Order Details] AS od, dbo.Products AS p
WHERE od.ProductID = p.ProductID
AND od.UnitPrice > 10
GROUP BY ProductName, od.ProductID
GO
CREATE UNIQUE CLUSTERED INDEX VdiscountInd on View4 (ProductName, ProductID)

查询 8

视图 4 的同一个索引还将用于一个添加了与表 Orders 的联接的查询。该查询符合以下条件:查询 FROM 子句中列出的表是索引视图的 FROM 子句中表的超集。

SELECT ProductName, od.ProductID, AVG(od.UnitPrice*(1.00-Discount))
AS AvgPrice, SUM(od.Quantity) AS Units
FROM dbo.[Order Details] AS od, dbo.Products AS p, dbo.Orders AS o
WHERE od.ProductID = p.ProductID and o.OrderID = od.OrderID
AND od.UnitPrice > 10
GROUP BY ProductName, od.ProductID

最后两个查询是查询 8 的变体。每个变体都违背了一个优化器条件,因此与查询 8 不同,不能使用视图 4。

查询 8a

由于视图定义中的 UnitPrice > 10 与查询中的 UnitPrice > 25 之间的 WHERE 子句不匹配,所以 Q8a 不能使用索引视图。查询搜索条件谓词必须是视图定义中搜索条件谓词的超集。

SELECT ProductName, od.ProductID, AVG(od.UnitPrice*(1.00-Discount)) AvgPrice,
SUM(od.Quantity) AS Units
FROM dbo.[Order Details] AS od, dbo.Products AS p, dbo.Orders AS o
WHERE od.ProductID = p.ProductID and o.OrderID = od.OrderID
AND od.UnitPrice > 25
GROUP BY ProductName, od.ProductID

查询 8b

注意,表 Orders 没有参与索引视图 V4 的定义。尽管如此,在该表中添加谓词将禁止使用索引视图,原因是添加的谓词可能会消除聚合中的其它行(如查询 8b 中所示)。

SELECT ProductName, od.ProductID, AVG(od.UnitPrice*(1.00-Discount))
AS AvgPrice, SUM(od.Quantity) AS Units
FROM dbo.[Order Details] AS od, dbo.Products AS p, dbo.Orders AS o
WHERE od.ProductID = p.ProductID and o.OrderID = od.OrderID
AND od.UnitPrice > 10
AND o.OrderDate > '01/01/1998'
GROUP BY ProductName, od.ProductID

有关详细信息

Microsoft SQL Server 2000 联机图书包含索引视图的详细信息。有关其它信息,请参阅以下资源:

Microsoft SQL Server Web 站点(英文)。
Microsoft SQL Server 开发人员中心(英文)。
SQL Server 杂志(英文)。
Microsoft.public.sqlserver.server 和 microsoft.public.sqlserver.datawarehouse 新闻组,其站点是:news://news.microsoft.com(英文)。
关于 SQL Server 的 Microsoft 正式课程。有关最新的课程信息,请参阅 Microsoft 培训和服务站点(英文)。

时间: 2024-11-03 13:44:19

用SQLServer2000索引视图提高性能(下)的相关文章

第十章——维护索引(7)——使用索引视图提高性能

原文:第十章--维护索引(7)--使用索引视图提高性能 前言: 视图是一个包含了一个或多个表的数据列的虚拟表.通常情况下,它仅仅是存储了查询的对象,一个视图可以当作一个表,可以用于存储过程.JOIN.用户自定义函数等等. 视图包含了下面两个主要特性: 1. 提供了一个安全机制,用于限制用户只能访问特定的数据. 2. 使得开发人员能定制用户的逻辑视图.   当你查询一个视图时,优化器会产生一个单一的执行计划给这个查询.在索引视图未出现之前,视图必须解决查询在执行期间才硬化.所有的JOIN.聚合都在

通过 SQL Server 2005 索引视图提高性能

本文介绍了 SQL Server 2005 Enterprise Edition 中经过改进的索引视图功能.文中对索引视图进行了说明介绍,并讨论了可通过该功能改善性能的一些具体情况 一.索引视图 多年以来,Microsoft SQL Server 一直支持创建称为视图的虚拟表.通常,这些视图的主要作用是: • 提供一种安全机制,将用户限制到一个或多个基表的某个数据子集中. • 提供一种机制,允许开发人员自定义用户通过逻辑方式查看存储在基表中的数据的方式. 通过 SQL Server 2000,S

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

server|视图|索引|性能 什么是索引视图? 许多年来,Microsoft SQL Server 一直都提供创建虚拟表(称为视图)的功能.在过去,这些视图主要有两种用途: 提供安全机制,将用户限制在一个或多个基表中的数据的某个子集. 提供一种机制,允许开发人员定制用户如何才能以逻辑方式查看存储在基表中的数据. SQL Server 2000 已经扩展了 SQL Server 视图的功能,以提高系统性能.它可以在一个视图上创建唯一的群集索引和非群集索引,可以改进最复杂查询的数据访问性能.在 S

用SQL Server 2005索引视图提高性能一

一.索引视图 多年以来,MicrosoftSQL Server一直支持创建称为视图的虚拟表.通常,这些视图的主要作用是: 提供一种安全机制,将用户限制到一个或多个基表的某个数据子集中. 提供一种机制,允许开发人员自定义用户通过逻辑方式查看存储在基表中的数据的方式. 通过 SQL Server 2000,SQL Server 视图的功能得到了扩展,实现了系统性能方面的收益.可在视图上创建唯一的聚集索引及非聚集索引,来提高最复杂的查询的数据访问性能.在 SQL Server 2000 和 2005

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

本文介绍 SQL Server 2000 企业版的新功能 - 索引视图.讲解索引视图并讨论一些提高性能的具体方案. 什么是索引视图? 许多年来,Microsoft SQL Server 一直都提供创建虚拟表(称为视图)的功能.在过去,这些视图主要有两种用途: 提供安全机制,将用户限制在一个或多个基表中的数据的某个子集. 提供一种机制,允许开发人员定制用户如何才能以逻辑方式查看存储在基表中的数据. SQL Server 2000 已经扩展了 SQL Server 视图的功能,以提高系统性能.它可以

用SQL Server 2005索引视图提高性能二

视图限制 如要在 SQL Server 2005 中的视图上创建一个索引,相应的视图定义必须包含: ANY.NOT ANY OPENROWSET.OPENQUERY.OPENDATASOURCE 不精确的(浮型.实型)值上的算术 OPENXML COMPUTE.COMPUTE BY ORDER BY CONVERT 生成一个不精确的结果 OUTER 联接 COUNT(*) 引用带有一个已禁用的聚集索引的基表 GROUP BY ALL 引用不同数据库中的表或函数 派生的表(FROM 列表中的子查询

ORA FAQ 性能调整系列之——压缩索引会提高性能么?

索引|性能|压缩 Will compressing my indexes improve performance ?压缩索引会提高性能么? Author's name: Jonathan Lewis Author's Email: Jonathan@jlcomp.demon.co.uk Date written: 26th Feb 2003 Oracle version(s): 8.1 - 9.2 Compressed indexes have been around for a couple

SQL Server中用索引视图查看性能状况

在SQL Server中,视图是一个保存的T-SQL查询.视图定义由SQL Server保存,以便它能够用作一个虚拟表来简化查询,并给基表增加另一层安全.但是,它并不占用数据库的任何空间.实际上,在你查询它之前,视图并不做任何事情. 索引视图 在SQL Server 2000和2005中,你能够给视图增加索引.但是,如果视图只是一个保存在数据库中的查询定义,在运行前没有自己的数据,你如何给那个定义建立一个索引呢?嗯,这比较麻烦. 索引视图是一个已被物化或保存在数据库中的视图.当基本表更新时,给视

SQL Server:创建索引视图

server|创建|视图|索引 视图也称为虚拟表,这是因为由视图返回的结果集其一般格式与由列和行组成的表相似,并且,在 SQL 语句中引用视图的方式也与引用表的方式相同.标准视图的结果集不是永久地存储在数据库中.查询每次引用视图时,Microsoft SQL Server 2000 会动态地将生成视图结果集所需的逻辑合并到从基表数据生成完整查询结果集所需的逻辑中.生成视图结果的过程称为视图具体化.有关更多信息,请参见视图解析. 对于标准视图而言,为每个引用视图的查询动态生成结果集的开销很大,特别