腳本之家服務(wù)器常用軟件

快捷導(dǎo)航

Sql Server查詢卡頓的排查方法

更新時間：2024年07月31日 10:42:43 作者：碼農(nóng)研究僧

這篇文章主要介紹了Sql Server查詢卡頓的排查方法,本文給大家介紹的非常詳細(xì),對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值,需要的朋友參考下吧

前言

本篇為理論知識的分析以及對癥下藥，前陣子發(fā)生過Bug，后通過遷移服務(wù)器以及數(shù)據(jù)庫最終才解決問題，但是細(xì)想當(dāng)時可能是因為碎片或者緩存的概率比較高

針對的SQL為SQL Server，其他的數(shù)據(jù)庫也同理

單查詢此條數(shù)據(jù)庫的時候應(yīng)用層代碼以及數(shù)據(jù)庫都報大量的錯誤

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

針對上述卡頓的情況，造成的原因有如下可能

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

沒有的話現(xiàn)加：（根據(jù)自身情況以及表格加入相應(yīng)的索引字段）

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

如果表碎片存在過多，可能會造成即使有查詢也會很緩慢

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

類似如下信息，那么需要重建索引來減少碎片了

運行索引重建或重組操作來減少碎片：

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

通過計劃緩存查詢是否有使用不佳的查詢計劃

也可嘗試清除緩存來重新查詢：DBCC FREEPROCCACHE;

表可能被其他事務(wù)鎖定，導(dǎo)致查詢等待

查詢是否有鎖的情況

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

上述情況為一個排查的方向

對于細(xì)節(jié)方向的把握，比如字段的不匹配，長度的不滿足都會有影響

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

還有服務(wù)器的負(fù)載，檢查是否服務(wù)器的性能有所干擾，定時任務(wù)或者其他資源都比較密集

還有一點如果數(shù)據(jù)量過大，需要對數(shù)據(jù)進(jìn)行更好的清洗

根據(jù)執(zhí)行計劃執(zhí)行語句的時候確保沒有使用全表查詢，深入分析查詢的瓶頸

到此這篇關(guān)于Sql Server查詢卡頓的排查方向的文章就介紹到這了,更多相關(guān)Sql Server查詢卡頓內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: