前言
SQL Server 效能監控並非一次性專案，而是持續迭代的過程。本文彙整資深 DBA 的實戰經驗，涵蓋監控清單客製化、記錄工具選擇、優先級劃分、問題分級處理、變更管理、基準測試、生產環境操作守則、回滾預案與長期維護策略，助你建構系統化的效能治理體系。
一、客製化你的監控清單
每個 SQL Server 安裝環境略有不同，通用清單需依實際架構（獨立/叢集/AlwaysOn）、工作負載（OLTP/OLAP/混合）、資料量、業務關鍵度進行裁剪與擴充。建議以本系列文章提供的清單為基礎，增刪項目使其貼合你的環境。
二、善用 Word/Excel 記錄監控結果
- 將清單項目複製至 Word 或 Excel 作為工作底本。
- 每台伺服器建立獨立工作表/文件。
- Excel 進階用法：列為監控項目，欄為各伺服器，可快速橫向比較差異。
三、設定伺服器與資料庫優先級
面對大量實例時，依業務影響度、SLA 要求、歷史故障頻率分級：
- P0：核心交易、即時決策系統 → 立即、高頻監控。
- P1：重要支援系統 → 定期監控。
- P2/P3：開發、測試、歸檔庫 → 低頻或按需監控。
依優先級排序執行，確保資源投入產出比最大化。
四、記住監控鐵律：先易後難、分級處理
- 辨識並修正容易問題：設定錯誤、索引缺失、統計資料過期、參數嗅探等。
- 將困難問題分級記錄：架構缺陷、硬體瓶頸、應用程式反模式等，留待專案時間深入根因分析。
- 建立問題追蹤清單：記錄發現時間、嚴重度、影響範圍、負責人、預計解決時間。
五、不要過早行動：監控先行，系統性實施
發現問題時切勿即時修改。完整執行監控流程，彙總發現，研判根因，制定變更計畫，再按計畫分批實施。避免「治標不治本」或引入新問題。
六、建議但常被忽略的步驟：效能基準測試
理想流程：變更前跑 Baseline → 實施變更 → 變更後跑 Baseline → 比對差異。
雖耗時，卻是驗證調校成效的唯一科學手段。若時間允許，務必執行；否則至少保留關鍵指標（Batch Requests/sec、Page Life Expectancy、Wait Stats 快照）作為事前事後參考。
七、變更實施原則：一次一個，可驗證
- 單一伺服器若需多項變更，採「一次一個或一小批」原則。
- 每批變更後觀察一段時間（至少一個業務週期），確認無副作用再進行下一批。
- 若一次上線多項變更導致異常，將無法快速定罪，被迫全量回滾再逐一測試，成本極高。
八、生產環境變更鐵律
- 先在測試環境驗證：相同版本、相似資料量、模擬負載。
- 單一變更、可回滾：每次僅一項變更，並預先撰寫回滾腳本。
- 選擇低峰時段：避開核心業務時段，預留緩衝時間。
- 通知利害關係人：DBA、開發、運維、業務擁有者共同知悉。
九、擁有「取消計劃」：備份是最後防線
- 關鍵變更前：完整備份使用者資料庫 + 主資料庫。
- 變更涉及結構調整：額外備份交易記錄，縮短 RPO。
- 記錄備份位置、還原步驟、預估 RTO，寫入變更單。
十、記錄所有變更：留存審計軌跡
將每項變更（時間、內容、負責人、觀察結果）記錄於監控清單或專用變更日誌。未來排查問題時，這是最有價值的線索來源。
十一、年度效能監控：制度化常態
環境會變：補丁套用、參數調整、資料增長、查詢模式演進。建立年度（或半年度）完整人工效能審計機制，補足自動化監控的盲區。
十二、完成首輪監控後：邁向深度調優
首輪監控解決的是「顯而易見、易修正」的問題。接下來需：
- 深入分析 Wait Stats、Query Store、擴充事件資料。
- 識別高耗資源查詢，進行查詢重寫、索引重設計、架構調整。
- 建立自動化異常偵測與告警（如 Query Store 自動調優、資料庫健康情況檢查）。
- 持續投入時間於「影響最大」的前 20% 問題，獲得 80% 效能提升。
結語
效能監控是馬拉松，非百米賽跑。建立制度、沉澱知識、分級處理、謹慎變更、持續迭代，方能在 SQL Server 生命週期中維持穩定高效的服務水準。祝你調優順利！
