当前位置：首页 > 站长知识 > 数据库 > 正文内容

Sql Server查询卡顿的排查方法

2024-11-29数据库44

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

1. 问题所示

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

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

1
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]';

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

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

2.2 表碎片

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

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

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

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

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

2.3 查询计划缓存

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

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

2.4 锁和阻塞

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

查询是否有锁的情况

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

3. 总结

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

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

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

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

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

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


相关文章

SQL Server计算两个时间相差2024-11-05
mysql服务无法启动怎么解决2024-11-27
SQL中的INNER JOIN用法详解2024-11-29
CentOS 9 Stream 安装部署 SQL Server 20192024-11-29
SQL Server怎么导入Excel数据2024-11-29
SQL报错注入之updatexml2024-11-29
SQL中的窗口函数2024-11-29
SQLserver日志优化2024-11-29
sqlserver迁移数据库文件存储位置2024-11-29

本站不销售产品、不代购、不提供技术支持，仅分享信息，请遵纪守法、文明上网。

Copyright © 2015-2024 国外主机测评. 闽ICP备2024075899号-2