SQL SEVER数据库重建索引的方法
Posted 有梦就能实现
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了SQL SEVER数据库重建索引的方法相关的知识,希望对你有一定的参考价值。
一.查询思路
1.想要判断数据库查询缓慢的问题,可以使用如下语句,可以列出查询语句的平均时间,总时间,所用的CPU时间等信息
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
SELECT creation_time N ‘语句编译时间‘ ,last_execution_time N ‘上次执行时间‘ ,total_physical_reads N ‘物理读取总次数‘ ,total_logical_reads/execution_count N ‘每次逻辑读次数‘ ,total_logical_reads N ‘逻辑读取总次数‘ ,total_logical_writes N ‘逻辑写入总次数‘ , execution_count N ‘执行次数‘ , total_worker_time/1000 N ‘所用的CPU总时间ms‘ , total_elapsed_time/1000 N ‘总花费时间ms‘ , (total_elapsed_time / execution_count)/1000 N ‘平均时间ms‘ , SUBSTRING (st.text, (qs.statement_start_offset/2) + 1, (( CASE statement_end_offset WHEN -1 THEN DATALENGTH(st.text) ELSE qs.statement_end_offsetEND - qs.statement_start_offset)/2) + 1) N ‘执行语句‘ FROM sys.dm_exec_query_stats AS qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st where SUBSTRING (st.text, (qs.statement_start_offset/2) + 1, (( CASE statement_end_offset WHEN -1 THEN DATALENGTH(st.text) ELSE qs.statement_end_offsetEND - qs.statement_start_offset)/2) + 1) not like ‘%fetch%‘ ORDER BY total_elapsed_time / execution_count DESC ; |
2.列出数据库每个表的数据量,并且需要运维人员对业务足够了解,知道大概哪些表是查询量最多的,可以查看“排在前面的表的磁盘使用情况”:
3.查看表碎片的情况,可以使用命令
DBCC SHOWCONTIG
可以看到该表扫描密度只有33.52%(最佳状态是100%,每个表页都写满数据),远远低于最佳计数,也就是说这个表的利用率很低,本来扫描一页 就能出结果,现在可能需要扫描三页,增加了查询时间;而逻辑碎片和区碎片都很多(一般认为超过30%就需要优化了),也就是说同样一页,数据很少而碎片很 多,占用了过多的数据库资源。 4.根据你对业务的了解,找出查询最多的表,对比他的数据,查询时间,和碎片程度可以判断出该表是否需要整理碎片,重建索引,以提高数据库性能。 重建索引的语句为:
use[数据库名] ALTER INDEX ALL ON [表名称] REBUILD;
重建后,同样的一张表NWME_Company_Index,再次查询表碎片情况的结果如下:
可以看到密度已经变为96.9%,而逻辑碎片几乎没有了。
5.现在可以看一下整理碎片后,是否真的对查询性能优化了,再次运行第一点列出的命令查看可以发现,大部分查询语句所用的平均时间都下降了接近一半:
现在可以到前台实际体验优化后的效果了。
以上是关于SQL SEVER数据库重建索引的方法的主要内容,如果未能解决你的问题,请参考以下文章
sql优化实战:从1353秒到135秒(删除索引+修改数据+重建索引)