MSSQL网页设计用SQLServer2000索引视图进步功能(下)

InnoDB事务型数据库的首选引擎，支持ACID事务，支持行级锁定server|sqlserver|视图|索引|功能利用“索引微调导游”

“索引微调导游”除倡议利用基表的索引以外，还倡议利用索引视图。利用该导游可进步办理员断定索引和索引视图相分离的才能，从而优化针对数据库实行的典范夹杂查询的功能。

因为“索引微调导游”强迫利用一切必须的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操纵。
查询优化器利用索引视图来天生查询企图。
SET
选项请求
的值默许
服务器
的值OLEDB
和
ODBC的值DBLIB
的值
ANSI_NULLSONOFFONOFF
ANSI_PADDINGONONONOFF
ANSI_WARNINGONOFFONOFF
ARITHABORTONOFFOFFOFF
CONCAT_NULL_YIELDS_NULLONOFFONOFF
NUMERIC_ROUNDABORTOFFOFFOFFOFF
QUOTED_IDENTIFIERONOFFONOFF


假如利用的是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语句所基于的视图可以在示例部分找到（视）。


别的请求

除“计划原则”、“利用SET选项以取得分歧的了局”和“利用断定性函数”部分中列出的请求以外，还必需切合以下请求。

基表请求

基表在创立时必需准确设置SET选项，不然就不克不及被包括架构绑定的视图援用。
表必需经由过程视图界说中的两部分称号（一切者.表名）援用。
函数请求

用户界说的函数必需利用WITHSCHEMABINDING选项创立。
用户界说的函数必需经由过程两部分称号（一切者.函数）援用。
视图请求

视图必需利用WITHSCHEMABINDING选项创立。
视图必需只援用统一数据库中的基表，而不克不及援用别的视图。
语法限定

对视图界说的语法有几个限定。视图界说不克不及包括以下内容：

COUNT(*)
ROWSET函数
派生表
自连接
DISTINCT
STDEV、VARIANCE、AVG
Float*列、文本列、ntext列、图象列
子查询
全文谓词（CONTAIN、FREETEXT）
可空表达式的SUM
MIN、MAX
TOP
OUTER连接
UNION
注重：索引视图能够包括浮动列，不外，此类列不克不及包括在聚集索引关头字中。

GROUPBY限定

假如未利用GROUPBY，表达式不克不及在选择列表中利用。

假如利用了GROUPBY，则VIEW界说：

必需包括COUNT_BIG(*)。
不得包括HAVING、CUBE或ROLLUP。
这些限定只合用于索引视图界说。查询能够在其实行企图中利用索引视图，即使该索引视图其实不切合这些GROUPBY限定。

索引请求

实行CREATEINDEX语句的用户必需是视图一切者。
假如视图界说中包括GROUPBY子句，独一聚集索引的关头字只能援用GROUPBY子句中指定的列。

示例

本部分的示例论述索引视图在两种次要查询（聚合和连接）中的利用成绩。同时还申明查询优化器在断定某个索引视图是不是可用时利用的前提。有关这些前提的完全列表，请参阅查询优化器怎样利用索引视图。

查询基于Northwind（SQLServer2000中供应的数据库样本）中的表，并能够写进的体例实行。创立视图的前后，最好利用SQL查询优化器中的“显现实行企图”工具来检察查询优化器选定的企图。只管示例中论述了优化器是怎样选择本钱最低的实行企图的，但由于Northwind数据库样本太小，因而没法表现功能的进步。

以下查询显现怎样从OrderDetails表中前往具有最年夜总扣头的五种产物的两个办法。

查询1

SELECTTOP5ProductID,SUM(UnitPrice*Quantity)-
SUM(UnitPrice*Quantity*(1.00-Discount))ASRebate
FROM[OrderDetails]
GROUPBYProductID
ORDERBYRebateDESC

查询2

SELECTTOP5ProductID,SUM(UnitPrice*Quantity*Discount)ASRebate
FROM[OrderDetails]
GROUPBYProductID
ORDERBYRebateDESC

查询优化器选定的实行企图包括：

对OrderDetails表的聚集索引扫描，估量有2,155行。
哈希婚配/聚合运算符，该运算符基于GROUPBY列将选定的行放进哈希表，然后盘算每行的SUM聚合。
基于ORDERBY子句的TOP5排序运算符。
视

增加包含Rebate列所需聚合的索引视图将变动查询1的查询实行企图。在数百万行的年夜表上，查询的功能也将分明进步。

CREATEVIEWVdiscount1WITHSCHEMABINDING
AS
SELECTSUM(UnitPrice*Quantity)ASSumPrice,
SUM(UnitPrice*Quantity*(1.00-Discount))
ASSumDiscountPrice,COUNT_BIG(*)ASCount,ProductID
FROMdbo.[OrderDetails]
GROUPBYProductID
GO
CREATEUNIQUECLUSTEREDINDEXVDiscountIndONVdiscount1(ProductID)

第一个查询的实行企图显现Vdiscount1视图由查询优化器利用。不外，因为该视图不包括SUM(UnitPrice*Quantity*Discount)聚合，因而不会被第二个查询利用。能够创立另外一个能够同时满意上述两个查询的索引视图。

视

CREATEVIEWVdiscount2WITHSCHEMABINDING
AS
SELECTSUM(UnitPrice*Quantity)ASSumPrice,
SUM(UnitPrice*Quantity*(1.00-Discount))ASSumDiscountPrice,
SUM(UnitPrice*Quantity*Discount)ASSumDiscountPrice2,COUNT_BIG(*)
ASCount,ProductID
FROMdbo.[OrderDetails]
GROUPBYProductID
GO
CREATEUNIQUECLUSTEREDINDEXVDiscountIndONVdiscount2(ProductID)

有了该索引视图，如今两个查询的查询实行企图包括：

对Vdiscount2视图的聚集索引扫描，估量有77行
基于ORDERBY子句的TOP5排序函数
查询优化器选择该视图是由于它供应了最低的实行本钱，只管在查询中并未援用该视图。

查询3

查询3相似于前几个查询，只是ProductID已被OrderID所代替，视图界说中没有包含该列。这违反了以下前提：查询选择列表中的一切表达式都必需能从未包含在视图界说内的表的视图选择列表中派生。

SELECTTOP3OrderID,SUM(UnitPrice*Quantity*Discount)OrderRebate
FROMdbo.[OrderDetails]
GROUPBYOrderID
ORDERBYOrderRebatedesc

请求独自的索引视图来满意该查询。能够对Vdiscount2举行修正，使它包含OrderID，可是所天生视图的行数将与原表的行数不异，因而，供应的功能也不会高于利用基表所供应的功能。

查询4

该查询可天生每一个产物的均匀代价。

SELECTProductName,od.ProductID,
AVG(od.UnitPrice*(1.00-Discount))ASAvgPrice,SUM(od.Quantity)ASUnits
FROM[OrderDetails]od,Productsp
WHEREod.ProductID=p.ProductID
GROUPBYProductName,od.ProductID

索引视图的界说中不克不及包含庞大的聚合（比方，STDEV、VARIANCE、AVG），不外，假如索引视图中包含几个团结起来实行庞大聚合的复杂聚合函数，便可用于实行包括AVG的查询。

视

该索引视图包括实行AVG函数所需的复杂聚合函数。在创立了视后实行查询4时，实行企图会显现正被利用的视图。优化器能够从视图的复杂聚合列Price和Count中导出AVG表达式。

CREATEVIEWView3WITHSCHEMABINDING
AS
SELECTProductID,SUM(UnitPrice*(1.00-Discount))ASPrice,
COUNT_BIG(*)ASCount,SUM(Quantity)ASUnits
FROMdbo.[OrderDetails]
GROUPBYProductID
Go
CREATEUNIQUECLUSTEREDINDEXiv3ONView3(ProductID)

查询5

该查询与查询4不异，只不外包含一个附加搜刮前提。即便该附加搜刮前提只援用未包含在视图界说内的表中的列，视也将用于该查询。

SELECTProductName,od.ProductID,AVG(od.UnitPrice*(1.00-Discount))
ASAvgPrice,SUM(od.Quantity)ASUnits
FROM[OrderDetails]ASod,ProductsASp
WHEREod.ProductID=p.ProductID
ANDp.ProductNamelike%Tofu%
GROUPBYProductName,od.ProductID

查询6

查询优化器不克不及将视用于该查询。附加搜刮前提od.UnitPrice>10包括视图界说内的表中的列，而该列却不呈现在GROUPBY列表中，搜刮谓词也不呈现在视图界说中。

SELECTProductName,od.ProductID,AVG(od.UnitPrice*(1.00-Discount))
ASAvgPrice,SUM(od.Quantity)ASUnits
FROM[OrderDetails]od,Productsp
WHEREod.ProductID=p.ProductID
ANDod.UnitPrice>10
GROUPBYProductName,od.ProductID

查询7

相反，查询优化器能够将视用于查询7，缘故原由是新搜刮前提od.ProductIDin(1,2,13,41)中界说的列包含在视图界说内的GROUPBY子句中。

SELECTProductName,od.ProductID,AVG(od.UnitPrice*(1.00-Discount))
ASAvgPrice,SUM(od.Quantity)ASUnits
FROM[OrderDetails]ASod,ProductsASp
WHEREod.ProductID=p.ProductID
ANDod.ProductIDin(1,2,13,41)
GROUPBYProductName,od.ProductID

视

该视图在视图界说中包含了列od.Discount，能够满意查询6的前提。

CREATEVIEWView4WITHSCHEMABINDING
AS
SELECTProductName,od.ProductID,SUM(od.UnitPrice*(1.00-Discount))
ASAvgPrice,SUM(od.Quantity)ASUnits,COUNT_BIG(*)ASCount
FROMdbo.[OrderDetails]ASod,dbo.ProductsASp
WHEREod.ProductID=p.ProductID
ANDod.UnitPrice>10
GROUPBYProductName,od.ProductID
GO
CREATEUNIQUECLUSTEREDINDEXVdiscountIndonView4(ProductName,ProductID)

查询8

视的统一个索引还将用于一个增加了与表Orders的连接的查询。该查询切合以下前提：查询FROM子句中列出的表是索引视图的FROM子句中表的超集。

SELECTProductName,od.ProductID,AVG(od.UnitPrice*(1.00-Discount))
ASAvgPrice,SUM(od.Quantity)ASUnits
FROMdbo.[OrderDetails]ASod,dbo.ProductsASp,dbo.OrdersASo
WHEREod.ProductID=p.ProductIDando.OrderID=od.OrderID
ANDod.UnitPrice>10
GROUPBYProductName,od.ProductID

最初两个查询是查询8的变体。每一个变体都违反了一个优化器前提，因而与查询8分歧，不克不及利用视。

查询8a

因为视图界说中的UnitPrice>10与查询中的UnitPrice>25之间的WHERE子句不婚配，以是Q8a不克不及利用索引视图。查询搜刮前提谓词必需是视图界说中搜刮前提谓词的超集。

SELECTProductName,od.ProductID,AVG(od.UnitPrice*(1.00-Discount))AvgPrice,
SUM(od.Quantity)ASUnits
FROMdbo.[OrderDetails]ASod,dbo.ProductsASp,dbo.OrdersASo
WHEREod.ProductID=p.ProductIDando.OrderID=od.OrderID
ANDod.UnitPrice>25
GROUPBYProductName,od.ProductID

查询8b

注重，表Orders没有介入索引视图V4的界说。只管云云，在该表中增加谓词将克制利用索引视图，缘故原由是增加的谓词大概会打消聚合中的别的行（如查询8b中所示）。

SELECTProductName,od.ProductID,AVG(od.UnitPrice*(1.00-Discount))
ASAvgPrice,SUM(od.Quantity)ASUnits
FROMdbo.[OrderDetails]ASod,dbo.ProductsASp,dbo.OrdersASo
WHEREod.ProductID=p.ProductIDando.OrderID=od.OrderID
ANDod.UnitPrice>10
ANDo.OrderDate>01/01/1998
GROUPBYProductName,od.ProductID


有关具体信息

MicrosoftSQLServer2000联机图书包括索引视图的具体信息。有关别的信息，请参阅以下资本：

MicrosoftSQLServerWeb站点（英文）。
MicrosoftSQLServer开辟职员中央（英文）。
SQLServer杂志（英文）。
Microsoft.public.sqlserver.server和microsoft.public.sqlserver.datawarehouse旧事组，其站点是：news://news.microsoft.com（英文）。
关于SQLServer的Microsoft正式课程。有关最新的课程信息，请参阅Microsoft培训和服务站点（英文）。
我们只需要把binlog文件反向执行，每个操作都执行逆操作即可。当然也不是所有的event都反转。Table_mapevent必须还是在Rows_log_event每个操作之前。

至于淘汰的问题，只能说在你的项目周期之内，微软应该都不会倒闭。

你可以简单地认为适合的就是好，不适合就是不好。

但换公司用MSSQL2K感觉自己好像根本就不了解MSSQL。什么DTS触发器以前根本没用过。

需要注意的一点，也是我使用过程中发现的一个问题。在建立function->schema->table后，如果在现有的分区表上建立没有显式声明的聚集索引时，分区表会自动变为非分区表。这一点很让我纳闷。

而SQLServer如果能像Oracle一样可以为登陆分配如：5%的cpu，10%的内存。就可以解决这个漏洞。

还不是性能有问题！否则面向对象的数据库早就实现了！建议使用CLR的地方一般是和应用的复杂程度或操作系统环境有很高的耦合度的场景。如你想构建复杂的算法，并且用到了大量的指针和高级数据模型。

外键的级联更能扩展可能大部分的同行在设计OLTP系统的时候都不愿意建立外键，都是通过程序来控制父子数据的完整性。

仓酷云

这一点很好的加强了profiler的功能。但是提到profiler提醒大家注意一点。windows2003要安装sp1补丁才能启动profiler。否则点击没有反应。