Sql Server查询卡顿的排查方法

前言

本篇为理论知识的分析以及对症下药，前阵子发生过Bug，后通过迁移服务器以及数据库最终才解决问题，但是细想当时可能是因为碎片或者缓存的概率比较高

1. 问题所示

针对的SQL为SQL Server，其他的数据库也同理

单查询此条数据库的时候应用层代码以及数据库都报大量的错误

select count(0) from [manong].[dbo].[yanjiuseng] where startTime > '2024-8-1 00:00:00' and endTime < '2024-8-1 23:59:59'

2. 原理分析

针对上述卡顿的情况，造成的原因有如下可能

2.1 缺乏索引

先查看此表有没有该索引字段：EXEC sp_helpindex '[manong].[dbo].[yanjiuseng]';

没有的话现加：（根据自身情况以及表格加入相应的索引字段）

CREATE INDEX IX_YanJiuSeng_StartTime_EndTime ON [manong].[dbo].[yanjiuseng](startTime, endTime);

2.2 表碎片

如果表碎片存在过多，可能会造成即使有查询也会很缓慢

DBCC ShowContig('[manong].[dbo].[yanjiuseng]')

类似如下信息，那么需要重建索引来减少碎片了

运行索引重建或重组操作来减少碎片：

-- 重建索引
ALTER INDEX ALL ON [manong].[dbo].[yanjiuseng] REBUILD;
-- 或者重组索引
ALTER INDEX ALL ON [manong].[dbo].[yanjiuseng] REORGANIZE;

2.3 查询计划缓存

通过计划缓存查询是否有使用不佳的查询计划

也可尝试清除缓存来重新查询：DBCC FREEPROCCACHE;

2.4 锁和阻塞

表可能被其他事务锁定，导致查询等待

查询是否有锁的情况

SELECT * FROM sys.dm_exec_requests WHERE blocking_session_id <> 0;

3. 总结

上述情况为一个排查的方向

对于细节方向的把握，比如字段的不匹配，长度的不满足都会有影响

SELECT COUNT(0) 
FROM [manong].[dbo].[yanjiuseng] 
WHERE startTime > '2024-07-22T00:00:00' AND endTime < '2024-07-22T23:59:59';

还有服务器的负载，检查是否服务器的性能有所干扰，定时任务或者其他资源都比较密集

还有一点如果数据量过大，需要对数据进行更好的清洗

根据执行计划执行语句的时候确保没有使用全表查询，深入分析查询的瓶颈

到此这篇关于Sql Server查询卡顿的排查方向的文章就介绍到这了,更多相关Sql Server查询卡顿内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！