SQL Server查询优化技术及索引

From: http://www.cnblogs.com/lovewindy/archive/2005/02/19/105959.html

 

在《数据库原理》里面，对聚簇索引的解释是:聚簇索引的顺序就是数据的物理存储顺序，而对非聚簇索引的解释是:索引顺序与数据物理排列顺序无关。正式因为如此，所以一个表最多只能有一个聚簇索引。

不过这个定义太抽象了。在SQL Server中，索引是通过二叉树的数据结构来描述的，我们可以这么理解聚簇索引：索引的叶节点就是数据节点。而非聚簇索引的叶节点仍然是索引节点，只不过有一个指针指向对应的数据块。如下图：

非聚簇索引

 

聚簇索引

聚簇索引与非聚簇索引的本质区别到底是什么？什么时候用聚簇索引，什么时候用非聚簇索引？

这是一个很复杂的问题，很难用三言两语说清楚。我在这里从SQL Server索引优化查询的角度简单谈谈(如果对这方面感兴趣的话，可以读一读微软出版的《Microsoft SQL Server 2000数据库编程》第3单元的数据结构引论以及第6、13、14单元)。

一、索引块与数据块的区别

大家都知道，索引可以提高检索效率，因为它的二叉树结构以及占用空间小，所以访问速度块。让我们来算一道数学题：如果表中的一条记录在磁盘上占用1000字节的话，我们对其中10字节的一个字段建立索引，那么该记录对应的索引块的大小只有10字节。我们知道，SQL Server的最小空间分配单元是“页（Page）”，一个页在磁盘上占用8K空间，那么这一个页可以存储上述记录8条，但可以存储索引800条。现在我们要从一个有8000条记录的表中检索符合某个条件的记录，如果没有索引的话，我们可能需要遍历8000条×1000字节/8K字节=1000个页面才能够找到结果。如果在检索字段上有上述索引的话，那么我们可以在8000条×10字节/8K字节=10个页面中就检索到满足条件的索引块，然后根据索引块上的指针逐一找到结果数据块，这样IO访问量要少的多。

二、索引优化技术

是不是有索引就一定检索的快呢？答案是否。有些时候用索引还不如不用索引快。比如说我们要检索上述表中的所有记录，如果不用索引，需要访问8000条×1000字节/8K字节=1000个页面，如果使用索引的话，首先检索索引，访问8000条×10字节/8K字节=10个页面得到索引检索结果，再根据索引检索结果去对应数据页面，由于是检索所有数据，所以需要再访问8000条×1000字节/8K字节=1000个页面将全部数据读取出来，一共访问了1010个页面，这显然不如不用索引快。

SQL Server内部有一套完整的数据检索优化技术，在上述情况下，SQL Server的查询计划（Search Plan）会自动使用表扫描的方式检索数据而不会使用任何索引。那么SQL Server是怎么知道什么时候用索引，什么时候不用索引的呢？SQL Server除了日常维护数据信息外，还维护着数据统计信息，下图是数据库属性页面的一个截图：

从图中我们可以看到，SQL Server自动维护统计信息，这些统计信息包括数据密度信息以及数据分布信息，这些信息帮助SQL Server决定如何制定查询计划以及查询是是否使用索引以及使用什么样的索引（这里就不再解释它们到底如何帮助SQL Server建立查询计划的了）。我们还是来做个实验。建立一张表：tabTest(ID, unqValue，intValue)，其中ID是整形自动编号主索引，unqValue是uniqueidentifier类型，在上面建立普通索引，intValue 是整形，不建立索引。之所以挂上一个没有索引的intValue字段，就是防止SQL Server使用索引覆盖查询优化技术，这样实验就起不到作用了。向表中录入10000条随机记录，代码如下：

 

CREATE TABLE [dbo].[tabTest] (
 [ID] [int] IDENTITY (1, 1) NOT NULL ,
 [unqValue] [uniqueidentifier] NOT NULL ,
 [intValue] [int] NOT NULL 
) ON [PRIMARY]
GO

ALTER TABLE [dbo].[tabTest] WITH NOCHECK ADD 
 CONSTRAINT [PK_tabTest] PRIMARY KEY  CLUSTERED 
 (
  [ID]
 )  ON [PRIMARY] 
GO

ALTER TABLE [dbo].[tabTest] ADD 
 CONSTRAINT [DF_tabTest_unqValue] DEFAULT (newid()) FOR [unqValue]
GO

CREATE  INDEX [IX_tabTest_unqValue] ON [dbo].[tabTest]([unqValue]) ON [PRIMARY]
GO

declare @i int
declare @v int

set @i=0
while @i<10000
begin
    set @v=rand()*1000    
    insert into tabTest ([intValue]) values (@v)
    set @i=@i+1
end

 

然后我们执行两个查询并查看执行计划，如图：（在查询分析器的查询菜单中可以打开查询计划，同时图上第一个查询的GUID是我从数据库中找的，大家做实验的时候可以根据自己数据库中的值来定）：

从图中可以看出，在第一个查询中，SQL Server使用了IX_tabTest_unqValue索引，根据箭头方向，计算机先在索引范围内找，找到后，使用Bookmark Lookup将索引节点映射到数据节点上，最后给出SELECT结果。在第二个查询中，系统直接遍历表给出结果，不过它使用了聚簇索引，为什么呢？不要忘了，聚簇索引的页节点就是数据节点！这样使用聚簇索引会更快一些（不受数据删除、更新留下的存储空洞的影响，直接遍历数据是要跳过这些空洞的）。

下面，我们在SQL Server中将ID字段的聚簇索引更改为非聚簇索引，然后再执行select * from tabTest，这回我们看到的执行计划变成了：

SQL Server没有使用任何索引，而是直接执行了Table Scan，因为只有这样，检索效率才是最高的。

三、聚簇索引与非聚簇索引的本质区别

现在可以讨论聚簇索引与非聚簇索引的本质区别了。正如本文最前面的两个图所示，聚簇索引的叶节点就是数据节点，而非聚簇索引的页节点仍然是索引检点，并保留一个链接指向对应数据块。

还是通过一道数学题来看看它们的区别吧：假设有一8000条记录的表，表中每条记录在磁盘上占用1000字节，如果在一个10字节长的字段上建立非聚簇索引主键，需要二叉树节点16000个（这16000个节点中有8000个叶节点，每个页节点都指向一个数据记录），这样数据将占用8000条×1000字节/8K字节=1000个页面；索引将占用16000个节点×10字节/8K字节=20个页面，共计1020个页面。

同样一张表，如果我们在对应字段上建立聚簇索引主键，由于聚簇索引的页节点就是数据节点，所以索引节点仅有8000个，占用10个页面，数据仍然占有1000个页面。

下面我们看看在执行插入操作时，非聚簇索引的主键为什么比聚簇索引主键要快。主键约束要求主键不能出现重复，那么SQL Server是怎么知道不出现重复的呢？唯一的方法就是检索。对于非聚簇索引，只需要检索20个页面中的16000个节点就知道是否有重复，因为所有主键键值在这16000个索引节点中都包含了。但对于聚簇索引，索引节点仅仅包含了8000个中间节点，至于会不会出现重复必须检索另外1000个页数据节点才知道，那么相当于检索10+1000=1010个页面才知道是否有重复。所以聚簇索引主键的插入速度要比非聚簇索引主键的插入速度慢很多。

让我们再来看看数据检索的效率，如果对上述两表进行检索，在使用索引的情况下（有些时候SQL Server执行计划会选择不使用索引，不过我们这里姑且假设一定使用索引），对于聚簇索引检索，我们可能会访问10个索引页面外加1000个数据页面得到结果（实际情况要比这个好），而对于非聚簇索引，系统会从20个页面中找到符合条件的节点，再映射到1000个数据页面上（这也是最糟糕的情况），比较一下，一个访问了1010个页面而另一个访问了1020个页面，可见检索效率差异并不是很大。所以不管非聚簇索引也好还是聚簇索引也好，都适合排序，聚簇索引仅仅比非聚簇索引快一点。

结语

好了，写了半天，手都累了。关于聚簇索引与非聚簇索引效率问题的实验就不做了，感兴趣的话可以自己使用查询分析器对查询计划进行分析。SQL Server是一个很复杂的系统，尤其是索引以及查询优化技术，Oracle就更复杂了。了解索引以及查询背后的事情不是什么坏事，它可以帮助我们更为深刻的了解我们的系统。

 

 

SQL Server基础知识之:设计和实现视图

设计和实现视图可谓是数据库物理设计中的一个非常重要的步骤。从一般意义上说，设计和实现视图应该遵循下面的一些建议和原则。

以下内容摘在文档，我对某些重点进行了补充说明（红色部分）

只能在当前数据库中创建视图。 但是，如果使用分布式查询定义视图，则新视图所引用的表和视图可以存在于其他数据库甚至其他服务器中。

• 分布式视图是可行的，但随着SQL Server本身能力的提高，例如SQL Server 2005开始支持表分区等技术之后，分布式视图应该尽量少用。
• 所谓分布式视图的一个最大的问题就是将表物理上分开在多个数据库甚至服务器中，这增加了维护和查询的难度

视图名称必须遵循标识符的规则，且对每个架构都必须唯一。 此外，该名称不得与该架构包含的任何表的名称相同。

• 一个可以借鉴的做法是：在视图名称之前添加一个前缀 vw

您可以对其他视图创建视图。Microsoft SQL Server 允许嵌套视图。但嵌套不得超过 32 层。 根据视图的复杂性及可用内存，视图嵌套的实际限制可能低于该值。

• 一般不建议超过2层

不能将规则或 DEFAULT 定义与视图相关联。

不能将 AFTER 触发器与视图相关联，只有 INSTEAD OF 触发器可以与之相关联。

• 除非万不得已，一般不建议使用触发器

定义视图的查询不能包含 COMPUTE 子句、COMPUTE BY 子句或 INTO 关键字。

• 很多朋友不知道：COMPUTER和COMPUTER BY语句仅仅用于一些特殊场合，用于生成总计行。大致有如下的效果

该特性不能用于视图，但可以直接用于查询

 

定义视图的查询不能包含 ORDER BY 子句，除非在 SELECT 语句的选择列表中还有一个 TOP 子句。

• 这个很有意思，如果要访问所有的呢，还必须是写TOP 100 PERCENT

定义视图的查询不能包含指定查询提示的 OPTION 子句。

定义视图的查询不能包含 TABLESAMPLE 子句。

• 关于TABLESAMPLE语句，大家可能也比较陌生，这是一个用于对数据进行抽样的。它和TOP语句不同，TOP语句是有固定大小的，而TABLESAMPLE返回的数据，可能多，可能少，甚至可能没有
• 我之前有一篇文章讲述这个语法 http://www.cnblogs.com/chenxizhang/archive/2009/05/19/1460040.html

不能为视图定义全文索引定义。

不能创建临时视图，也不能对临时表创建视图。

• 在SQL Server 2005中，可以通过CTE（Common Table Expression)来实现该功能
• 之前的版本，大致的做法是使用临时表，表变量，函数等等

不能删除参与到使用 SCHEMABINDING 子句创建的视图中的视图、表或函数，除非该视图已被删除或更改而不再具有架构绑定。 另外，如果对参与具有架构绑定的视图的表执行 ALTER TABLE 语句，而这些语句又会影响该视图的定义，则这些语句将会失败。

• 如果未使用 SCHEMABINDING 子句创建视图，则对视图下影响视图定义的对象进行更改时，应运行 sp_refreshview。 否则，当查询视图时，可能会生成意外结果。
  • 如果你修改了一个表，那么如何刷新所有与该表有关的视图呢
    • http://msdn.microsoft.com/zh-cn/library/ms187821(SQL.90).aspx
• 强烈建议对某些非常重要的视图，添加SCHEMABINDING 子句。

尽管查询引用一个已配置全文索引的表时，视图定义可以包含全文查询，仍然不能对视图执行全文查询。

下列情况下必须指定视图中每列的名称：

• 视图中的任何列都是从算术表达式、内置函数或常量派生而来。
• 视图中有两列或多列原应具有相同名称（通常由于视图定义包含联接，因此来自两个或多个不同表的列具有相同的名称）。
• 希望为视图中的列指定一个与其源列不同的名称。 （也可以在视图中重命名列。） 无论重命名与否，视图列都会继承其源列的数据类型。

  若要创建视图，您必须获取由数据库所有者授予的此操作执行权限，如果使用 SCHEMABINDING 子句创建视图，则必须对视图定义中引用的任何表或视图具有相应的权限。

  默认情况下，由于行通过视图进行添加或更新，当其不再符合定义视图的查询的条件时，它们即从视图范围中消失。 例如，创建一个定义视图的查询，该视图从表中检索员工的薪水低于 $30,000 的所有行。如果员工的薪水涨到 $32,000，因其薪水不符合视图所设条件，查询时视图不再显示该特定员工。 但是，WITH CHECK OPTION 子句强制所有数据修改语句均根据视图执行，以符合定义视图的 SELECT 语句中所设条件。 如果使用该子句，则对行的修改不能导致行从视图中消失。 任何可能导致行消失的修改都会被取消，并显示错误。