當懷疑硬體資源成為 SQL Server 瓶頸時，可透過 效能監視器 追蹤下列關鍵計數器，快速定位問題根因。
記憶體相關
Memory: Pages/sec
- 偶爾飆高 → 瞬時執行緒搶佔記憶體
- 持續偏高 → 記憶體不足為主要瓶頸，需加裝實體記憶體或限制 SQL Server 最大記憶體
Process: Working Set (sqlservr)
- 應接近指派給 SQL Server 的記憶體上限
sp_configure 'set working set size' 預設 0 (由 OS 管理)，建議保持預設，勿強制鎖定
CPU 相關
Process: % Processor Time (sqlservr)
- 持續 > 95% → CPU 瓶頸，考慮增加核心、升級 CPU、或優化高耗 CPU 查詢（排序、聚合、錯誤計畫）
Processor: % Privileged Time
- 若與 Physical Disk 計數器同步偏高 → I/O 子系統瓶頸（磁碟速度不足、RAID 卡故障、tempdb 壓力大）
- 緩解措施：
Tempdb in RAM、降低 max async IO、max lazy writer IO
Processor: % User Time
- 反映排序、聚合函數等使用者模式運算
- 偏高時：增加索引、簡化聯結、水平分割大表
磁碟 I/O 相關
Physical Disk: Avg. Disk Queue Length
- 建議值 ≤ 磁碟數量 × 1.5~2
- 超標 → 增加磁碟、調整 RAID 等級、分離資料/記錄/Tempdb 至不同磁碟組
- 注意：RAID 陣列內含多顆實體磁碟，計算時以實體磁碟數為準
SQL Server 專屬
SQLServer: Cache Hit Ratio
- 越高越好，持續 < 80% → 記憶體壓力大，考慮加大記憶體
- 注意：此計數器為啟動後累積值，長時間運行無法反映即時狀態，建議搭配
sys.dm_os_performance_counters 計算增量比率
實務上建議建立基準線，定期擷取計數器歷程，異常時才能快速比對。結合 DMV (sys.dm_os_wait_stats, sys.dm_exec_query_stats) 可從等待類型與查詢統計雙向佐證。
