大多数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] (如果小于 100%,则存在碎片。)
Best Count是连续链接时的理想区域改变数,Actual Count是实际区域改变数,Scan Density为100%表示没有分块。
Logical Scan Fragmentation 扫描索引页中失序页的百分比 逻辑扫描碎片(如果为0是最好)
Extent Scan Fragmentation 不实际相邻和包含链路中所有链接页的区域数
Avg. Bytes Free per Page 扫描页面中平均自由字节数
Avg. Page Density (full) 平均页密度,表示页有多满 平均页密度(完整)(如果为100%是最好)
从上面命令的执行结果可以看的出来,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%。
3.重建整个数据库的索引
USE [DATABASE]
EXEC SP_MSFOREACHTABLE 'DBCC DBREINDEX(''?'')'