SQL SERVER 索引（聚集索引和非聚集索引）

今天下午，看了一些关于聚集索引和非聚集索引的知识，现在把它整理出来。

一、准备知识：

不论是 聚集索引，还是非聚集索引，都是用B+树来实现的。我们在了解这两种索引之前，需要先了解B+树。如果你对B树不了解的话，建议参看以下几篇文章：
B+ 树的结构图:



B+ 树的特点:

所有关键字都出现在叶子结点的链表中（稠密索引），且链表中的关键字恰好是有序的；

不可能在非叶子结点命中；

非叶子结点相当于是叶子结点的索引（稀疏索引），叶子结点相当于是存储（关键字）数据的数据层；

二、举个通俗的例子来说明聚集索引和非聚集索引的区别：

汉语字典的正文本身就是一个聚集索引。比如，我们要查“安”字，就会很自然地翻开字典的前几页，因为“安”的拼音是“an”，而按照拼音排序汉字的字典是以英文字母“a”开头并以“z”结尾的，那么“安”字就自然地排在字典的前部。如果您翻完了所有以“a”开头的部分仍然找不到这个字，那么就说明您的字典中没有这个字；同样的，如果查“张”字，那您也会将您的字典翻到最后部分，因为“张”的拼音是“zhang”。也就是说，字典的正文部分本身就是一个目录，您不需要再去查其他目录来找到您需要找的内容。正文内容本身就是一种按照一定规则排列的目录称为“聚集索引”。
如果您认识某个字，您可以快速地按拼音查字法查到这个字。但您也可能会遇到您不认识的字，不知道它的发音，这时候，您就不能按照刚才的方法找到您要查的字，而需要去根据“偏旁部首”查到您要找的字，然后根据这个字后的页码直接翻到某页来找到您要找的字。但您结合“部首目录”和“检字表”而查到的字的排序并不是真正的正文的排序方法，比如您查“张”字，我们可以看到在查部首之后的检字表中“张”的页码是672页，检字表中“张”的上面是“驰”字，但页码却是63页，“张”的下面是“弩”字，页面是390页。很显然，这些字并不是真正的分别位于“张”字的上下方，现在您看到的连续的“驰、张、弩”三字实际上就是他们在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我们可以通过这种方式来找到您所需要的字，但它需要两个过程，先找到目录中的结果，然后再翻到您所需要的页码。
三、聚集索引

聚集索引确定表中数据的物理顺序。聚集索引类似于电话簿，后者按姓氏排列数据。由于聚集索引规定数据在表中的物理存储顺序，因此一个表只能包含一个聚集索引。但该索引可以包含多个列（组合索引），就像电话簿按姓氏和名字进行组织一样。

聚集索引在系统数据库表sysindexes 内有一行，其 indid = 1。数据链内的页和其内的行按聚集索引键值排序。所有插入都在所插入行中的键值与排序顺序相匹配时执行。

SQL Server将索引组织为B-树。索引内的每一页包含一个页首，页首后面跟着索引行。每个索引行都包含一个键值以及一个指向较低级页或数据行的指针。索引的每个页称为索引节点。B-树的顶端节点称为根节点。索引的底层节点称为叶节点。每级索引中的页链接在双向链接列表中。在聚集索引内数据页组成叶节点。根和叶之间的任何索引级统称为中间级。

对于聚集索引，sysindexes.root 指向它的顶端。SQL Server 沿着聚集索引浏览以找到聚集索引键对应的行。为找到键的范围，SQL Server 浏览索引以找到这个范围的起始键值，然后用向前或向后指针扫描数据页。为找到数据页链的首页，SQL Server 从索引的根节点开始沿最左边的指针进行扫描.

聚集索引对于那些经常要搜索范围值的列特别有效。使用聚集索引找到包含第一个值的行后，便可以确保包含后续索引值的行在物理相邻。例如，如果应用程序执行的一个查询经常检索某一日期范围内的记录，则使用聚集索引可以迅速找到包含开始日期的行，然后检索表中所有相邻的行，直到到达结束日期。这样有助于提高此类查询的性能。同样，如果对从表中检索的数据进行排序时经常要用到某一列，则可以将该表在该列上聚集（物理排序），避免每次查询该列时都进行排序，从而节省成本。

下面是两副简单描述聚集索引的示意图：



一个比较抽象点的聚集索引图示：



对于聚集索引，人们往往有一些错误的认识。其中，最常见的错误有：

l 聚集索引会降低insert操作的速度，因为必须要向后移动一半的数据来为新插入的行腾出空间。这种认识是错误的，因为可以利用填充因子控制填充的百分比，从而在索引页上为新插入的数据保留空间。如果索引页填满了，SQL Server将会进行页拆分，在这种情况下只有第一个页才会受到影响。

l 在使用标识列的主键上创建聚集索引是一种好的设计方法，它可以使对表的操作达到最快速度。这种认识是错误的，它浪费了创建其它更有效的聚集索引的机会。并且，使用这种方法会把每个新插入的记录行都存储到表尾部的同一个的数据页中，这将导致数据库的热点和锁争用。笔者曾经见过采用这种方法设计的数据库，对于每一个新订单，客户服务人员都不得不等待数分钟来加以确认。

l 聚集索引是具有魔力的。如果哪个查询的速度不够快，那么就在该列上创建聚集索引，对于表的操作速度一定会得到提高。这种认识也是错误的，聚集索引只是比非聚集索引稍稍快了那么一点点。因为在每个表上只能创建一个聚集索引，所以它也是一种宝贵的性能资源，只有在那些经常作为条件查询一组记录行的列上才应该建立聚集索引。

在创建聚集索引之前，应先了解数据是如何被访问的。可考虑将聚集索引用于：

l 包含大量非重复值的列。

l 使用下列运算符返回一个范围值的查询：BETWEEN、>、>=、< 和 <=。

l 被连续访问的列。

l 返回大型结果集的查询。

l 经常被使用联接或 GROUP BY 子句的查询访问的列；一般来说，这些是外键列。对 ORDER BY 或 GROUP BY 子句中指定的列进行索引，可以使 SQL Server 不必对数据进行排序，因为这些行已经排序。这样可以提高查询性能。

l OLTP 类型的应用程序，这些程序要求进行非常快速的单行查找（一般通过主键）。应在主键上创建聚集索引。

四、非聚集索引

非聚集索引与课本中的索引类似。数据存储在一个地方，索引存储在另一个地方，索引带有指针指向数据的存储位置。索引中的项目按索引键值的顺序存储，而表中的信息按另一种顺序存储（这可以由聚集索引规定）。如果在表中未创建聚集索引，则无法保证这些行具有任何特定的顺序。

典型的桌面数据库使用的是非聚集索引。在这类索引中，索引键值是有序的，而每个索引节点所指向的数据行是无序的。一个SQL Server表最多可以拥有249个非聚集索引。

非聚集索引与聚集索引一样有 B-树结构，但是有两个重大差别：

l 数据行不按非聚集索引键的顺序排序和存储。

l 非聚集索引的叶层不包含数据页。

相反，叶节点包含索引行。每个索引行包含非聚集键值以及一个或多个行定位器，这些行定位器指向有该键值的数据行（如果索引不唯一，则可能是多行）。非聚集索引可以在有聚集索引的表、堆集或索引视图上定义。在 SQL Server中，非聚集索引中的行定位器有式：

l 如果表是堆集（没有聚集索引），行定位器就是指向行的指针。该指针用文件标识符 (ID)、页码和页上的行数生成。整个指针称为行 ID。

l 如果表有聚集索引或索引视图上有聚集索引，则行定位器是行的聚集索引键。如果聚集索引不是唯一的索引，SQL Server 将添加在内部生成的值（称为唯一值）以使所有重复键唯一。此四字节的值对于用户不可见。仅当需要使聚集键唯一以用于非聚集索引中时，才添加该值。SQL Server 通过使用存储在非聚集索引的叶行内的聚集索引键搜索聚集索引来检索数据行。

由于非聚集索引将聚集索引键作为其行指针存储，因此使聚集索引键尽可能小很重要。如果表还有非聚集索引，请不要选择大的列作为聚集索引的键。

在创建非聚集索引之前，应先了解您的数据是如何被访问的。可考虑将非聚集索引用于：

l 包含大量非重复值的列，如姓氏和名字的组合（如果聚集索引用于其它列）。如果只有很少的非重复值，如只有 1 和 0，则大多数查询将不使用索引，因为此时表扫描通常更有效。

l 不返回大型结果集的查询。

l 返回精确匹配的查询的搜索条件（WHERE 子句）中经常使用的列。

l 经常需要联接和分组的决策支持系统应用程序。应在联接和分组操作中使用的列上创建多个非聚集索引，在任何外键列上创建一个聚集索引。

l 在特定的查询中覆盖一个表中的所有列。这将完全消除对表或聚集索引的访问。



一个比较抽象点的非聚集索引图示：



本文部分来自CSDN博客，并做了大量的修改，转载请标明出处：http://blog.csdn.net/a9529lty/archive/2009/11/14/4811401.aspx