SQL server 重建索引进程被牺牲 sql重建索引很慢

转载

boyboy 2023-08-25 18:46:02

文章标签 sql server 优化 table 数据库 database 文章分类 SQL Server 数据库

这两天在现场处理一则系统性能的问题，问题一在于数据库访问速度慢，有时一条语句运行速度会大于400ms；另一个问题在于数据库文件超大，mdf文件将近30G。

首先分析问题一，使用profiler跟踪数据库语句的执行情况，发现针对个别表的访问速度大大低于预期，发现此表日常记录维持在100w量级，并且数据操作非常频繁。使用sp_spaceused返回结果发现此表

rowsinfo reserved datainfo index_size unused
1105481 539248 KB 169744 KB 294280 KB 75224 KB

数据量和索引量都不小，结合此表的特征判断应该是索引的问题影响了效率，查看表设计虽然建立了一些非聚集索引，但是重复性很大，效率不高；另外通过DBCC SHOWCONTIG查找了一下表的健康情况，返回如下：

/*
DBCC SHOWCONTIG 正在扫描 'SC_CIG_INFO' 表...
表: 'SC_CIG_INFO' (1099150961)；索引 ID: 1，数据库 ID: 7
已执行 TABLE 级别的扫描。
- 扫描页数................................: 20563
- 扫描区数..............................: 2994
- 区切换次数..............................: 7394
- 每个区的平均页数........................: 6.9
- 扫描密度 [最佳计数:实际计数].......: 34.77% [2571:7395]
- 逻辑扫描碎片 ..................: 36.29%
- 区扫描碎片 ..................: 91.02%
- 每页的平均可用字节数........................: 375.3
- 平均页密度(满).....................: 95.36%
*/

可见健康指数（扫描密度，Scan Density）非常低下。故而判断原因应该如此。下面的工作就是优化索引项目和重建索引，此处不再多说。

在此顺带说一下索引的一些知识：

大多数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.

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

　　信息描述

表或索引中的长页数

表或索引中的长区页数

DBCC遍历页时从一个区域到另一个区域的次数

相关区域中的页数

　　Best Count是连续链接时的理想区域改变数，Actual Count是实际区域改变数，Scan Density为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%。

注意：

需要注意的是，重建非聚集索引时该表会暂时加上共享锁，对用户不可进行SELECT以外的操作；重建聚集索引时该表会暂时加上排外锁，不允许任何用户访问。因此需要制定好计划来预防可能的访问问题。

fillfactor这个指标是一个决定因子，那么它应该如何设置更合适呢？==========

REBUILD有一个fill factor参数，如果fill factor设置为100%，这意味着每一个索引页都是完全满的，如果fill factor设置为50%意味着每个索引页都是半满的。对于fill factor 100%，每次新插入或更新一个记录，由于当前页没有空间可用，可能有分页情况产生。过多的分页会降低SQL Server的性能。下面具体举个例子：

假设您在一张表上建立了一个使用默认fill factor的新索引。当SQL Server创建索引时，它会把索引放置在连续的物理页上，以使数据顺序地被读，I/O访问最优化。但当表因INSERT，UPDATE，DELETE等操作增长改变时，分页发生，SQL Server在磁盘的其他地方分配新的页，导致新的页与原物理页不连续，增加了随机I/O，访问索引页变慢。

那么fill factor的合适值应该为多少？这取决于表的读/写比：

低更新表（读/写比：100比1）：100% fill factor

高更新表（写超过读）：50%-70% fill factor

居中：80%-90% fill factor

过低的fill factor会增加页的数量，也会导致更多的页需要被移至缓存，缓存中有用的数据减少。默认的fill factor为0（即100% fill factor），通常这不是个好的选择，特别是对于聚集索引。

如果您无法判断设置什么fill factor,您首先需要确定磁盘的读/写比.方法就是使用如下两个计数器:

Physical Disk Object: % Disk Read Time 和 Physical Disk Object: % Write Time。另外一个可能有用的计数器就是：SQL Server Access Methods: Pages Splits/Sec。这个计数器测量SQL Server内每秒分页的次数。如果该数值过高，您需要降低fill factor防止新的分页。

如果您想确认您的索引因分页产生的碎片程度，您可以运行DBCC SHOWCONTIG命令。如果看特定表和特定索引，您可以运行如下代码：

结果集中最重要的参数是Scan Density，越接近100%越好。如果Scan Density小于75%，那么您可能需要重建表中的索引。

--获取每个索引的碎片情况

--Declare variables 
DECLARE
@ID int,
@IndexID int,
@IndexName varchar(128)
 
--Set the table and index to be examined 
SELECT= 'index_name' --enter name of index 
SET= OBJECT_ID('table_name') --enter name of table 
 
--Get the Index Values 
SELECT=
FROMsysindexes
WHERE= @ID AND name =
 
--Display the fragmentation 
DBCC(@id, @IndexID)
 
--获取当前表基本索引的碎片情况
 
 
 
--Declare variables 
DECLARE
@ID int

--Set the table and index to be examined 
SET= OBJECT_ID('table_name') --enter name of 
 
--Display the fragmentation 
DBCC(@id)

对于小于100数据页，重建索引并不会有明显的性能改善。这是因为物理硬件缓存，SQL Server缓存和SQL Server预读机制隐藏了碎片的负面作用。但对于非常大的表，重建索引会使它受益匪浅，因为涉及大量磁盘I/O操作。

如果有管理维护的需要，可以设定一个作业来后台执行如下自定义代码来更新某个数据库中所有表上的索引：

DECLAREvarchar(255)
 
DECLARECURSOR FOR
SELECTFROM information_schema.tables
WHERE= 'base table'
 
OPEN TableCursor 
 
FETCHNEXT FROM TableCursor INTO
WHILE@@FETCH_STATUS =
BEGIN
DBCC(@TableName,' ',90)
FETCHNEXT FROM TableCursor INTO
END
 
CLOSE TableCursor 
 
DEALLOCATE TableCursor

另外，更新了索引最好也重新更新一下统计信息，好处在于：

1. index建立后，优化器是否使用该index，优化器需要借助一些统计信息来做判断

2. 根据统计信息，预估采用嵌套循环连接，合并连接，哈希连接等哪一个连接

3. 根据统计信息判断表的估计最佳的成本（最佳的执行顺序），

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。