大多数SQL Server表需要 索引 来 提高 数据的访问速度，如果没有 索引 ，SQL Server 要进行表格扫描读取表中的每一个记录才能找到索要的数据。 索引 可以分为簇 索引 和非簇 索引 ，簇 索引 通过重排表中的数据来 提高 数据的访问速度，而非簇 索引 则通过维
大多数SQL Server表需要 索引 来 提高 数据的访问速度，如果没有 索引 ，SQL Server 要进行表格扫描读取表中的每一个记录才能找到索要的数据。 索引 可以分为簇 索引 和非簇 索引 ，簇 索引 通过重排表中的数据来 提高 数据的访问速度，而非簇 索引 则通过维护表中的数据指针来 提高 数据的 索引 。
1. 索引 的体系结构
为什么要不断的维护表的 索引 ？首先，简单介绍一下 索引 的体系结构。SQL Server在硬盘中用8KB页面在数据库文件内存放数据。缺省情况下这些页面及其包含的数据是无组织的。为了使混乱变为有序，就要生成 索引 。生成 索引 后，就有了 索引 页和数据页，数据页保存用户写入的数据信息。 索引 页存放用于检索列的数据值清单（关键字）和 索引 表中该值所在纪录的地址指针。 索引 分为簇 索引 和非簇 索引 ，簇 索引 实质上是将表中的数据排序，就好像是字典的 索引 目录。非簇 索引 不对数据排序，它只保存了数据的指针地址。向一个带簇 索引 的表中插入数据，当数据页达到100%时，由于页面没有空间插入新的的纪录，这时就会发生分页，SQL Server 将大约一半的数据从满页中移到空页中，从而生成两个半的满页。这样就有大量的数据空间。簇 索引 是双向链表，在每一页的头部保存了前一页、后一页地址以及分页后数据移动的地址，由于新页可能在数据库文件中的任何地方，因此页面的链接不一定指向磁盘的下一个物理页，链接可能指向了另一个区域，这就形成了分块，从而减慢了系统的速度。对于带簇 索引 和非簇 索引 的表来说，非簇 索引 的关键字是指向簇 索引 的，而不是指向数据页的本身。
为了克服数据分块带来的负面影响，需要重构表的 索引 ，这是非常费时的，因此只能在需要时进行。可以通过DBCC SHOWCONTIG来确定是否需要重构表的 索引 。
2. DBCC SHOWCONTIG用法
下面举例来说明DBCC SHOWCONTIG和DBCC REDBINDEX的使用方法。以应用程序中的Employee数据表作为例子，在 SQL Server的Query analyzer输入命令：
use database_name
declare @table_id int
set @table_id=object_id('Employee')
dbcc showcontig(@table_id)
输出结果：
DBCC SHOWCONTIG scanning 'Employee' table...
Table: 'Employee' (1195151303); index ID: 1, database ID: 53
TABLE level scan performed.
- Pages Scanned................................: 179
- Extents Scanned..............................: 24
- Extent Switches..............................: 24
- Avg. Pages per Extent........................: 7.5
- Scan Density [Best Count:Actual Count].......: 92.00% [23:25]
- Logical Scan Fragmentation ..................: 0.56%
- Extent Scan Fragmentation ...................: 12.50%
- Avg. Bytes Free per Page.....................: 552.3
- Avg. Page Density (full).....................: 93.18%
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
通过分析这些结果可以知道该表的 索引 是否需要重构。如下描述了每一行的意义：
信息 描述
Pages Scanned 表或 索引 中的长页数
Extents Scanned 表或 索引 中的长区页数
Extent Switches DBCC遍历页时从一个区域到另一个区域的次数
Avg. Pages per Extent 相关 区域中的页数
Scan Density[Best Count:Actual Count]
Best Count是连续链接时的理想区域改变数，Actual Count是实际区域改变数，Scan Density为100%表示没有分块。
Logical Scan Fragmentation 扫描 索引 页中失序页的百分比
Extent Scan Fragmentation 不实际相邻和包含链路中所有链接页的区域数
Avg. Bytes Free per Page 扫描页面中平均自由字节数
Avg. Page Density (full) 平均页密度，表示页有多满
从上面命令的执行结果可以看的出来，Best count为23 而Actual Count为25这表明orders表有分块需要重构表 索引 。下面通过DBCC DBREINDEX来重构表的簇 索引 。
3. DBCC DBREINDEX 用法
重建 指定数据库中表的一个或多个 索引 。
语法
DBCC DBREINDEX
( [ 'database.owner.table_name'
[ , index_name
[ , fillfactor ]
]
]
)
参数
'database.owner.table_name'
是要 重建 其指定的 索引 的表名。数据库、所有者和表名必须符合标识符的规则。有关更多信息，请参见使用标识符。如果提供 database 或 owner 部分，则必须使用单引号 (') 将整个 database.owner.table_name 括起来。如果只指定 table_name，则不需要单引号。
index_name
是要 重建 的 索引 名。 索引 名必须符合标识符的规则。如果未指定 index_name 或指定为 ' '，就要对表的所有 索引 进行 重建 。
fillfactor
是创建 索引 时每个 索引 页上要用于存储数据的空间百分比。fillfactor 替换起始填充因子以作为 索引 或任何其它 重建 的非聚集 索引 （因为已 重建 聚集 索引 ）的新默认值。如果 fillfactor 为 0，DBCC DBREINDEX 在创建 索引 时将使用指定的起始 fillfactor。
同样在Query Analyzer中输入命令：
dbcc dbreindex('database_name.dbo.Employee','',90)
然后再用DBCC SHOWCONTIG查看重构 索引 后的结果：
DBCC SHOWCONTIG scanning 'Employee' table...
Table: 'Employee' (1195151303); index ID: 1, database ID: 53
TABLE level scan performed.
- Pages Scanned................................: 178
- Extents Scanned..............................: 23
- Extent Switches..............................: 22
- Avg. Pages per Extent........................: 7.7
- Scan Density [Best Count:Actual Count].......: 100.00% [23:23]
- Logical Scan Fragmentation ..................: 0.00%
- Extent Scan Fragmentation ...................: 0.00%
- Avg. Bytes Free per Page.....................: 509.5
- Avg. Page Density (full).....................: 93.70%
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
通过结果我们可以看到Scan Denity为100%。
原文链接：《如何 提高 SQL SERVER的 性能 》
http://www.csdn.com.cn/database/1142.htm查看更多关于重建索引提高SQLServer性能的详细内容...