SqlServer查询卡顿的排查方法,
目录
- 前言
- 1. 问题所示
- 2. 原理分析
- 2.1 缺乏索引
- 2.2 表碎片
- 2.3 查询计划缓存
- 2.4 锁和阻塞
- 3. 总结
前言
本篇为理论知识的分析以及对症下药,前阵子发生过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查询卡顿内容请搜索PHP之友以前的文章或继续浏览下面的相关文章希望大家以后多多支持PHP之友!
您可能感兴趣的文章:- SQL Server数据库的死锁详细说明
- SQL Server死锁问题的排查和解决方法
- SQL server内存问题排查方案
- sql server卡慢问题定位与排查过程
- sql server排查死锁优化性能
- sql server中死锁排查的全过程分享
本站文章为和通数据库网友分享或者投稿,欢迎任何形式的转载,但请务必注明出处.
同时文章内容如有侵犯了您的权益,请联系QQ:970679559,我们会在尽快处理。