廣告：

前言

由于昨晚線上服務器數據庫突然訪問數據緩慢，任務管理里面SQL server進程爆滿等等，重大事故的排查擬寫解決方案。

整體思路

查詢數據庫請求連接：排查連接池是否占滿

查詢數據庫請求量：排查數據是否存在反復查詢

查詢數據庫阻塞語句以及執行語句：排查數據庫是否存在歷史SQL語句阻塞以及當前執行的SQL語句是否存在問題

查詢數據庫語句執行時間：排查數據庫是否因為數據量過大導致的

定位到問題指定位置

查詢數據庫請求連接

SELECT DB_NAME(dbid) AS DatabaseName, COUNT(*) AS ConnectionCount 
FROM sys.sysprocesses
WHERE dbid > 0
GROUP BY dbid;

查看連接池比較正常，除了master主數據庫存在大量連接，其他業務數據庫正常，猜測應該是排查人員的連接池，不太確定具體原因，但是排除連接池超量的問題。

查詢數據庫請求量

SELECT client_net_address AS '客戶端IP', COUNT(*) AS '請求次數'
FROM sys.dm_exec_connections
GROUP BY client_net_address
ORDER BY COUNT(*) DESC;

通過SQL語句排查是否存在大量重復數據請求量，顯然并不是請求次數的問題，也就是說沒有頻繁的請求量，因此排除數據請求頻繁的問題。

查詢數據庫阻塞語句以及執行語句

SELECT TOP 100 dest.[text] AS 'sql語句',session_id,status,start_time FROM sys.[dm_exec_requests] AS der CROSS APPLY sys.[dm_exec_sql_text](der.[sql_handle]) AS dest ORDER BY [cpu_time] DESC

查詢到數據庫正在執行的SQL語句并不存在阻塞的SQL語句，發現當前在執行的SQL語句比較正常，單獨執行這些SQL語句并不存在大量數據訪問，最多六千條數據量，這個量很小，因此無法確定，但是可以確定數據庫不存在問題，SQL語句也比較正常。

查詢數據庫語句執行時間

SELECT --TOP 20 
total_worker_time / 1000 AS [自編譯以來執行所用的CPU時間總量(ms)],
 total_elapsed_time/1000 as [完成執行此計劃所用的總時間],
 total_elapsed_time / execution_count/1000 as [平均完成執行此計劃所用時間],
 execution_count as [上次編譯以來所執行的次數], 
 creation_time as [編譯計劃的時間],
 deqs.total_worker_time / deqs.execution_count / 1000 AS [平均使用CPU時間(ms)],
 last_execution_time AS [上次開始執行計劃的時間],
 total_physical_reads [編譯后在執行期間所執行的物理讀取總次數],
 total_logical_reads/execution_count [平均邏輯讀次數],
 min_worker_time /1000 AS [單次執行期間所用的最小CPU時間(ms)],
 max_worker_time / 1000 AS [單次執行期間所用的最大 CPU 時間(ms)],
 SUBSTRING(dest.text, deqs.statement_start_offset / 2 + 1,  
 (CASE
  WHEN deqs.statement_end_offset = -1 THEN
  DATALENGTH(dest.text)  
  ELSE deqs.statement_end_offset
 END - deqs.statement_start_offset
 ) / 2 + 1) AS [執行SQL],
 dest.text as [完整SQL],
 db_name(dest.dbid) as [數據庫名稱],
 object_name(dest.objectid, dest.dbid) as [對象名稱]
 ,deqs.plan_handle [查詢所屬的已編譯計劃]
 FROM sys.dm_exec_query_stats deqs WITH(NOLOCK)
 CROSS APPLY sys.dm_exec_sql_text(deqs.sql_handle) AS dest
WHERE (max_worker_time / 1000)>100
 --完成執行此計劃所用的總時間降序
 ORDER BY total_elapsed_time/1000 DESC

從SQL語句執行時間分析出（后補的圖忽略第一個刪除的操作），整體分析下來是 tb_SN 和 tb_SNs 兩張表耗時嚴重，接下來只需使用查詢語句查詢兩張表數量即可。

問題分析與定位

查詢序列號表 tb_SN

SELECT COUNT(*) FROM tb_SN

243779 條

排查不是序列號表的問題，那么就只有序列號流水表的問題啦

查詢序列號流水表 tb_SNs

 SELECT COUNT(*) FROM tb_SNs

使用該命令果然執行時間緩慢，因此可以判斷是數據量太大導致的。

使用壓縮存儲快速查看數據量

點擊 tb_SNs 流水表 【右鍵】【存儲】【管理壓縮】【下一步】

流水表五千萬條數據，因此可以確定序列號流水表存在數據量過多導致的，整個和序列號流水相關的程序出現訪問緩慢的問題。

竟然知道問題了，和相關領導咨詢是否可以刪除數據，并確定刪除的時限范圍，確定刪除 2023 年以前的所有數據，釋放數據量。

首先我們備份整個數據庫防止誤操作，然后復制并創建與 tb_SNs 的數據結構相同的表，接下來將 2023 年以前的所有數據拷貝到該表上，最后在刪除 tb_SNs 的 2023 年以前的所有數據。

如此操作下，我們發現刪除的數據量只有十萬條，顯然這是不對的，總共三年不到，不可能只有怎么點數據，因此判斷是不是某個時間點插入大量數據，然后我們根據去年年份查詢去年的數據量：

SELECT TOP 10 COUNT(*) FROM tb_SNs WHERE CreationDate < '2024-01-01'
571638

五十萬條顯然是今年數據量突然增加的，因此開始查詢月時間節點產生的數據，發現三月以前都正常，數據出現在三月份，接下來開始查詢每日的數據量，三月五號正常，三月六號出現五千萬數據，因此問題出現在昨天的時候。

解析問題

接下來問題就好解決啦，首先根據主要數據查詢事故發生節點，再通過事故發生節點咨詢是否出現錯誤操作。

查詢負責人該節點人員工作安排

根據業務確定程序是否存在邏輯判斷插入問題

判斷數據是否可以刪除

廣告：