一.查询思路

1.想要判断数据库查询缓慢的问题,可以使用如下语句,可以列出查询语句的平均时间,总时间,所用的CPU时间等信息

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.现在可以看一下整理碎片后,是否真的对查询性能优化了,再次运行第一点列出的命令查看可以发现,大部分查询语句所用的平均时间都下降了接近一半:

现在可以到前台实际体验优化后的效果了。

标签:
SQLSEVER,数据库,重建索引

免责声明:本站文章均来自网站采集或用户投稿,网站不提供任何软件下载或自行开发的软件! 如有用户或公司发现本站内容信息存在侵权行为,请邮件告知! 858582#qq.com
评论“SQL SEVER数据库重建索引的方法”
暂无“SQL SEVER数据库重建索引的方法”评论...

RTX 5090要首发 性能要翻倍!三星展示GDDR7显存

三星在GTC上展示了专为下一代游戏GPU设计的GDDR7内存。

首次推出的GDDR7内存模块密度为16GB,每个模块容量为2GB。其速度预设为32 Gbps(PAM3),但也可以降至28 Gbps,以提高产量和初始阶段的整体性能和成本效益。

据三星表示,GDDR7内存的能效将提高20%,同时工作电压仅为1.1V,低于标准的1.2V。通过采用更新的封装材料和优化的电路设计,使得在高速运行时的发热量降低,GDDR7的热阻比GDDR6降低了70%。