先確認問題邊界，不要立刻調參數
接到「資料庫變慢」的告警後，第一步不是重啟服務、加大連線池或修改索引，而是定義退化的範圍與起始時間。先確認延遲是出現在單一 API、特定租戶、讀取流量、寫入流量，還是整個資料庫；同時比較應用程式延遲、資料庫查詢時間與連線取得時間。若應用程式等待連線，但已送達資料庫的查詢仍然正常，問題可能在連線池或大量併發，而不是 SQL 本身。
建立一條精確的事件時間線，對照部署、資料匯入、排程工作、流量變化、結構調整、參數修改、備份及故障切換。不要只看目前狀態，因為阻塞可能已解除，快取也可能在重啟後重新暖機。應優先保存慢查詢紀錄、等待事件、鎖定關係、作用中連線、CPU、記憶體、磁碟延遲、IOPS、網路延遲與複寫落後等當下證據。
- 影響範圍：哪些服務、查詢類型、資料表、節點或區域受到影響？
- 時間特徵：效能是瞬間下降、逐步惡化，還是只在固定時段出現？
- 資源特徵：CPU、記憶體、儲存或連線數是否接近限制？
- 變更事件：異常前是否有部署、批次作業、資料量成長或統計資訊更新？
用等待事件區分「忙碌」與「被卡住」
CPU 使用率高並不等於 CPU 是根因。資料庫可能因大量掃描而消耗 CPU，也可能因磁碟緩慢、鎖競爭或遠端儲存延遲而讓工作排隊。排查時應查看資料庫正在等待什麼，再把等待類型與主機及雲端監控對照。若 CPU 高且執行佇列持續增加，應檢查高成本查詢與錯誤的查詢計畫；若磁碟延遲增加而吞吐量接近儲存層上限，則需要找出造成大量讀寫的查詢，而不是只升級 CPU。
鎖定問題要從阻塞鏈的源頭看起。最久的查詢不一定是罪魁禍首，它可能只是等待一個處於閒置交易、批次更新或結構變更中的連線。檢查最上游的阻塞者、交易開始時間、持有的鎖，以及呼叫來源。直接終止連線雖能快速恢復服務，卻可能觸發大型回滾並延長壓力；在採取動作前，應先估算交易規模、資料一致性風險與應用程式是否會自動重試。
比較正常基準，檢查查詢計畫與工作負載
突然退化通常代表某個條件跨過臨界點，例如資料分布改變、統計資訊過期、參數型別不一致、索引失效、資料量超出原本計畫假設，或新版本改變了 SQL。應將異常期間與正常期間的高耗時查詢依總時間、平均時間、執行次數、掃描資料量及暫存空間使用量比較。總耗時高但單次正常，通常是呼叫量暴增；單次耗時突然增加，則更值得檢查執行計畫與資料分布。
閱讀執行計畫時，不要只尋找全表掃描。要比較估算列數與實際列數、連接順序、索引選擇、排序或雜湊是否溢寫到磁碟，以及隱含型別轉換是否讓索引無法使用。新增索引也不是零成本方案：它會增加寫入、儲存與維護負擔。若問題來自短期批次工作，限制批次大小或調整執行時段可能比永久新增索引合理；若核心線上查詢持續走錯計畫，才應考慮更新統計資訊、改寫查詢、建立合適索引或使用經過驗證的計畫控制機制。
先止血，再用單一變更驗證根因
緊急處置應選擇可回復、影響範圍明確的動作。可考慮暫停非必要批次、限制昂貴查詢的併發、降低應用程式重試頻率、切斷已確認的阻塞來源，或將可接受稍舊資料的讀取導向健康副本。盲目擴大連線池往往會增加資料庫併發與記憶體壓力；直接擴容可能暫時降低延遲，卻也可能掩蓋錯誤計畫或無界限查詢。每次只做一項主要變更，記錄時間與預期指標，才能判斷措施是否真正有效。
服務恢復後，應把事件轉化為可重複的防護：保留查詢層級的歷史基準、對連線池與儲存延遲設定告警、為交易及查詢建立合理逾時、限制批次大小，並在部署流程檢查結構變更與高風險 SQL。復盤需要回答的不只是「哪一段 SQL 很慢」，還包括為何監控沒有更早顯示、哪個保護機制失效，以及下次如何在不登入正式環境臨時查找的情況下取得同樣證據。跨越應用、雲端與資料庫層的事件，通常也最適合由熟悉整合邊界的工程團隊共同處理。