重建索引提高SQL Server性能<转>

本文涉及的产品
RDS SQL Server Serverless,2-4RCU 50GB 3个月
推荐场景:
云数据库 RDS SQL Server,基础系列 2核4GB
简介:

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

1.  索引的体系结构
        SQL Server 2005 在硬盘中用 8KB 页面在数据库文件内存放数据。缺省情况下这些页面及其包含的数据是无组织的。为了使混乱变为有序,就要生成索引。生成索引后,就有了索引页和数据页之分:数据页用来保存用户写入的数据信息;索引页存放用于检索列的数据值清单(关键字)和索引表中该值所在纪录的地址指针。索引分为簇索引和非簇索引,簇索引实质上是将表中的数据排序,就好像是字典的索引目录。非簇索引不对数据排序,它只保存了数据的地址。向一个带簇索引的表中插入数据,当数据页达到 100% 时,由于页面没有空间插入新的的纪录,这时就会发生分页, SQL Server  将大约一半的数据从满页中移到空页中,从而生成两个1/2满页。这样就有大量的空的数据空间。簇索引是双向链表,在每一页的头部保存了前一页、后一页以及分页后数据移出的地址。由于新页可能在数据库文件中的任何地方,因此页面的链接不一定指向磁盘的下一个物理页。链接可能指向了另一个区域,这就形成了分块,从而减慢了系统的速度。对于带簇索引和非簇索引的表来说,非簇索引的关键字是指向簇索引的,而不是指向数据页的本身。
        为了克服数据分块带来的负面影响,需要重构表的索引,这是非常费时的,因此只能在需要时进行。 可以通过 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%

原文地址:http://fly3118.blog.51cto.com/361030/83836



本文转自温景良(Jason)博客园博客,原文链接:http://www.cnblogs.com/wenjl520/archive/2010/07/11/1775089.html如需转载请自行联系原作者

版权说明
相关实践学习
使用SQL语句管理索引
本次实验主要介绍如何在RDS-SQLServer数据库中,使用SQL语句管理索引。
SQL Server on Linux入门教程
SQL Server数据库一直只提供Windows下的版本。2016年微软宣布推出可运行在Linux系统下的SQL Server数据库,该版本目前还是早期预览版本。本课程主要介绍SQLServer On Linux的基本知识。 相关的阿里云产品:云数据库RDS&nbsp;SQL Server版 RDS SQL Server不仅拥有高可用架构和任意时间点的数据恢复功能,强力支撑各种企业应用,同时也包含了微软的License费用,减少额外支出。 了解产品详情:&nbsp;https://www.aliyun.com/product/rds/sqlserver
相关文章
|
3月前
|
SQL 存储 关系型数据库
如何巧用索引优化SQL语句性能?
本文从索引角度探讨了如何优化MySQL中的SQL语句性能。首先介绍了如何通过查看执行时间和执行计划定位慢SQL,并详细解析了EXPLAIN命令的各个字段含义。接着讲解了索引优化的关键点,包括聚簇索引、索引覆盖、联合索引及最左前缀原则等。最后,通过具体示例展示了索引如何提升查询速度,并提供了三层B+树的存储容量计算方法。通过这些技巧,可以帮助开发者有效提升数据库查询效率。
271 2
|
2月前
|
SQL 数据库 UED
SQL性能提升秘籍:5步优化法与10个实战案例
在数据库管理和应用开发中,SQL查询的性能优化至关重要。高效的SQL查询不仅可以提高应用的响应速度,还能降低服务器负载,提升用户体验。本文将分享SQL优化的五大步骤和十个实战案例,帮助构建高效、稳定的数据库应用。
102 3
|
2月前
|
SQL IDE 数据库连接
IntelliJ IDEA处理大文件SQL:性能优势解析
在数据库开发和管理工作中,执行大型SQL文件是一个常见的任务。传统的数据库管理工具如Navicat在处理大型SQL文件时可能会遇到性能瓶颈。而IntelliJ IDEA,作为一个强大的集成开发环境,提供了一些高级功能,使其在执行大文件SQL时表现出色。本文将探讨IntelliJ IDEA在处理大文件SQL时的性能优势,并与Navicat进行比较。
39 4
|
2月前
|
SQL 存储 缓存
如何优化SQL查询性能?
【10月更文挑战第28天】如何优化SQL查询性能?
187 10
|
2月前
|
SQL 关系型数据库 MySQL
惊呆:where 1=1 可能严重影响性能,差了10多倍,快去排查你的 sql
老架构师尼恩在读者交流群中分享了关于MySQL中“where 1=1”条件的性能影响及其解决方案。该条件在动态SQL中常用,但可能在无真实条件时导致全表扫描,严重影响性能。尼恩建议通过其他条件或SQL子句命中索引,或使用MyBatis的`&lt;where&gt;`标签来避免性能问题。他还提供了详细的执行计划分析和优化建议,帮助大家在面试中展示深厚的技术功底,赢得面试官的青睐。更多内容可参考《尼恩Java面试宝典PDF》。
|
2月前
|
SQL 缓存 监控
SQL性能提升指南:五大优化策略与十个实战案例
在数据库性能优化的世界里,SQL优化是提升查询效率的关键。一个高效的SQL查询可以显著减少数据库的负载,提高应用响应速度,甚至影响整个系统的稳定性和扩展性。本文将介绍SQL优化的五大步骤,并结合十个实战案例,为你提供一份详尽的性能提升指南。
63 0
|
3月前
|
SQL Oracle 关系型数据库
SQL优化-使用联合索引和函数索引
在一次例行巡检中,发现一条使用 `to_char` 函数将日期转换为字符串的 SQL 语句 CPU 利用率很高。为了优化该语句,首先分析了 where 条件中各列的选择性,并创建了不同类型的索引,包括普通索引、函数索引和虚拟列索引。通过对比不同索引的执行计划,最终确定了使用复合索引(包含函数表达式)能够显著降低查询成本,提高执行效率。
|
3月前
|
SQL 关系型数据库 MySQL
如何确认SQL用了索引:详细技巧与方法
在数据库管理中,索引是提高SQL查询性能的重要手段
|
3月前
|
SQL 监控 数据库
慢SQL对数据库写入性能的影响及优化技巧
在数据库管理系统中,慢SQL(即执行缓慢的SQL语句)不仅会影响查询性能,还可能对数据库的写入性能产生显著的不利影响
|
3月前
|
SQL 关系型数据库 PostgreSQL
遇到SQL 子查询性能很差?其实可以这样优化
遇到SQL 子查询性能很差?其实可以这样优化
161 2