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 SHOWCONTIGDBCC REDBINDEX的使用方法。以应用程序中Employee数据作为例子,在 SQL ServerQuery 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........................

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值