详细分析 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';

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

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

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