目录
- 前言
- 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';
还有服务器的负载，检查是否服务器的性能有所干扰，定时任务或者其他资源都比较密集
还有一点如果数据量过大，需要对数据进行更好的清洗
根据执行计划执行语句的时候确保没有使用全表查询，深入分析查询的瓶颈
