前幾天WXC給我反應說最近今天網站老是出現卡頓。心裏咯噔一下，不會是IIS要出什麼問題吧o(╥﹏╥)o。然後遠程服務器排查了一波，看程序日誌沒異常的（排除程序問題），windows記錄的系統日誌和程序日誌也沒什麼特殊異常（排除系統問題），cpu和內存佔用也還好（排除佔cpu和內存），程序sql、方法、性能日誌也沒開（排除io操作卡頓）。這樣只能懷疑是服務器一年多沒重啓導致的，當晚進行了服務器重啓。結果第二天還是有卡頓，並且反饋連儀器都能卡掉線。通過儀器卡掉線可以定位是數據庫執行M就慢了，開始了排查數據庫問題，先看Caché日誌看看ECP是不是和小機之間有通信故障（實際沒有），然後看license佔用是不是用完了（也沒有），然後看看有沒有異常進程在執行（也沒發現什麼線索）。數據庫慢肯定是有異常執行邏輯導致的，到底會是什麼呢？當時我也陷入困惑，想了一會兒突然想到之前碰到過項目有別的組的程序死循環了導致數據庫執行操作特別慢的事。那是不是也存在一個死循環或者類型死循環的東西一直在搶佔數據庫呢。從數據庫進程上已經排除了儀器接口的可能性，那麼可能是我們的定時任務導致的，因爲庫上掛了推送消息任務，繪圖任務，轉移當天標本任務，統計任務等等。有可能就是他們引起的，然後就一個個到terminal裏面調試任務方法。最後還真發現了推送消息任務奇慢的問題。該任務配置一分鐘執行一次，但是一次執行就超過一分鐘了，這不就是個死循環了嗎_
查詢要推送的消息都執行了類型下面的SQL
SELECT * FROM dbo.OT_MsgStock WHERE MsgType='HISReportUndo' AND IsReply=0
這個表沒有查詢兩個條件的索引
由於這個表數據是越來越大的，已經上億了，導致SQL沒有索引找基本遍歷的全表（可不慢嗎 這點和關係數據庫的索引優化是一樣的）
添加索引編譯後原來一個查詢要20秒的只要0秒了，而推消息邏輯有六七個這樣的查詢，執行一輪就是幾分鐘，結合消息一分鐘一執行的配置。實際數據庫就一直在幹全表掃描和比對的事。導致科室卡頓的原因就是他沒誰嘍。
發現跟蹤問題採用排查法縮小範圍不失爲一種好方法。