大多数SQL Server表需要索引来提高数据的访问速度，如果没有索引，SQL Server要进行表格扫描读取表中的每一个记录才能找到索要的数据。索引可以分为簇索引和非簇索引，簇索引通过重排表中的数据来提高数据的访问速度，而非簇索引则通过维护表中的数据指针来提高数据的索引。

　　索引的体系结构：

　　为什么要不断的维护表的索引？首先，简单介绍一下索引的体系结构。SQL Server在硬盘中用8KB页面在数据库文件内存放数据。缺省情况下这些页面及其包含的数据是无组织的。为了使混乱变为有序，就要生成索引。生成索引后，就有了索引页和数据页，数据页保存用户写入的数据信息。索引页存放用于检索列的数据值清单（关键字）和索引表中该值所在纪录的地址指针。索引分为簇索引和非簇索引，簇索引实质上是将表中的数据排序，就好像是字典的索引目录。非簇索引不对数据排序，它只保存了数据的指针地址。向一个带簇索引的表中插入数据，当数据页达到100%时，由于页面没有空间插入新的的纪录，这时就会发生分页，SQL Server 将大约一半的数据从满页中移到空页中，从而生成两个半的满页。这样就有大量的数据空间。簇索引是双向链表，在每一页的头部保存了前一页、后一页地址以及分页后数据移动的地址，由于新页可能在数据库文件中的任何地方，因此页面的链接不一定指向磁盘的下一个物理页，链接可能指向了另一个区域，这就形成了分块，从而减慢了系统的速度。对于带簇索引和非簇索引的表来说，非簇索引的关键字是指向簇索引的，而不是指向数据页的本身。

　　为了克服数据分块带来的负面影响，需要重构表的索引，这是非常费时的，因此只能在需要时进行。可以通过DBCC SHOWCONTIG来确定是否需要重构表的索引。下面举例来说明DBCC SHOWCONTIG和DBCC REDBINDEX的使用方法。以SQL Server自带的northwind数据作为例子

　　带开SQL Server的Query analyzer输入命令：

　　use pubs

　　declare @table_id int

　　set @table_id=object_id（'tbldlvinfoback'）

　　dbcc showcontig（@table_id）

　　这个命令显示pubs数据库中的tbldlvinfoback表的分块情况，结果如下：

　　DBCC SHOWCONTIG 正在扫描 'tblDlvInfoback' 表…

　　表： 'tblDlvInfoback'（1797581442）；索引 ID: 0,数据库 ID: 5

　　已执行 TABLE 级别的扫描。

　　- 扫描页数……： 197214

　　- 扫描扩展盘区数……： 24659

　　- 扩展盘区开关数……： 24658

　　- 每个扩展盘区上的平均页数……： 8.0

　　- 扫描密度[最佳值：实际值]……： 99.97%[24652:24659]

　　- 扩展盘区扫描碎片……： 15.46%

　　- 每页上的平均可用字节数……： 374.6

　　- 平均页密度（完整）……： 95.37%

　　DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

　　通过分析这些结果可以知道该表的索引是否需要重构。表1.1描述了每一行的意义描述

　　Pages Scanned          表或索引中的长页数

　　Extents Scanned         表或索引中的长区页数

　　Extent Switches         DBCC遍历页时从一个区域到另

　　一个区域的次数

　　Avg. Pages per Extent            相关区域中的页数

　　Scan Density                  Best Count是连续链接时的理想区

　　[Best Count:Actual Count]        域改变数，Actual Count是实际区

　　域改变数，Scan Density为100%

　　表示没有分块。

　　Logical Scan Fragmentation      扫描索引页中失序页的百分比

　　Extent Scan Fragmentation        不实际相邻和包含链路中所有链[page]
　　接页的区域数

　　Avg. Bytes Free per Page         扫描页面中平均自由字节数

　　Avg. Page Density （full）           平均页密度，表示页有多满

　　从上面命令的执行结果可以看的出来，Best count为3 而Actual Count为5这表明orders表有分块需要重构表索引。下面通过DBCC DBREINDEX来重构表的簇索引。

　　同样在Query Analyzer中输入命令：

　　use northwind

　　dbcc dbreindex（'northwind.dbo.orders',pk_orders,90）

　　执行结果：

　　DBCC execution completed. If DBCC printed error messages, contact your system administrator.

　　Dbcc dbreindex参数说明：第一个参数为要重构的表明。第二个参数为需要重构的索引表识，''表示所有的索引。第三个参数为页的填充因子，填充因子越大，页越满。

　　然后再用DBCC SHOWCONTIG查看重构簇索引后的结果：

　　use northwind

　　declare @table_id int

　　set @table_id=object_id（'orders'）

　　dbcc showcontig（@table_id）

　　返回结果如下：

　　DBCC SHOWCONTIG scanning 'Orders' table…

　　Table: 'Orders' （21575115）； index ID: 1, database ID: 6

　　TABLE level scan performed.

　　- Pages Scanned……： 22

　　- Extents Scanned……： 3

　　- Extent Switches……： 2

　　- Avg. Pages per Extent……： 7.3

　　- Scan Density [Best Count:Actual Count]……： 100.00% [3:3]

　　- Logical Scan Fragmentation ……： 0.00%

　　- Extent Scan Fragmentation ……： 33.33%

　　- Avg. Bytes Free per Page……： 869.2

　　- Avg. Page Density （full）……： 89.26%

　　DBCC execution completed. If DBCC printed error messages, contact your system administrator.

　　通过结果我们可以看到Scan Denity为100%表没有分块不需要重构表索引了。如果重构表的簇索引Scan Denity还小于100%的话可以重构表的全部索引。命令如下：

　　--use northwind

　　--dbcc dbreindex（'northwind.dbo.orders','',90）

　　使用作业定时重构索引：

　　如果你的数据库访问非常频繁的话，非常容易出现数据分块的现象，因此你可以利用作业来帮你在系统相对空闲的时候重构你的索引。

　　为什么要不断的维护表的索引？首先，简单介绍一下索引的体系结构。SQL Server在硬盘中用8KB页面在数据库文件内存放数据。缺省情况下这些页面及其包含的数据是无组织的。为了使混乱变为有序，就要生成索引。生成索引后，就有了索引页和数据页，数据页保存用户写入的数据信息。索引页存放用于检索列的数据值清单（关键字）和索引表中该值所在纪录的地址指针。索引分为簇索引和非簇索引，簇索引实质上是将表中的数据排序，就好像是字典的索引目录。非簇索引不对数据排序，它只保存了数据的指针地址。向一个带簇索引的表中插入数据，当数据页达到100%时，由于页面没有空间插入新的的纪录，这时就会发生分页，SQL Server 将大约一半的数据从满页中移到空页中，从而生成两个半的满页。这样就有大量的数据空间。簇索引是双向链表，在每一页的头部保存了前一页、后一页地址以及分页后数据移动的地址，由于新页可能在数据库文件中的任何地方，因此页面的链接不一定指向磁盘的下一个物理页，链接可能指向了另一个区域，这就形成了分块，从而减慢了系统的速度。对于带簇索引和非簇索引的表来说，非簇索引的关键字是指向簇索引的，而不是指向数据页的本身。

　　为了克服数据分块带来的负面影响，需要重构表的索引，这是非常费时的，因此只能在需要时进行。可以通过DBCC SHOWCONTIG来确定是否需要重构表的索引。下面举例来说明DBCC SHOWCONTIG和DBCC REDBINDEX的使用方法。以SQL Server自带的northwind数据作为例子

　　带开SQL Server的Query analyzer输入命令：

　　use pubs

　　declare @table_id int

　　set @table_id=object_id（'tbldlvinfoback'）

　　dbcc showcontig（@table_id）

　　这个命令显示pubs数据库中的tbldlvinfoback表的分块情况，结果如下：

　　DBCC SHOWCONTIG 正在扫描 'tblDlvInfoback' 表…

　　表： 'tblDlvInfoback'（1797581442）；索引 ID: 0,数据库 ID: 5

　　已执行 TABLE 级别的扫描。

　　- 扫描页数……： 197214

　　- 扫描扩展盘区数……： 24659

　　- 扩展盘区开关数……： 24658

　　- 每个扩展盘区上的平均页数……： 8.0

　　- 扫描密度[最佳值：实际值]……： 99.97%[24652:24659]

　　- 扩展盘区扫描碎片……： 15.46%

　　- 每页上的平均可用字节数……： 374.6

　　- 平均页密度（完整）……： 95.37

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。