記憶體管理機制深度解析
啟動階段
- SQL Server **不會立即佔用 Min Memory**。
- 僅配置啟動所需初始記憶體 (如 20MB)。
成長階段
- 負載增加 → Buffer Pool 繼續申請記憶體。
- **未達 Min Memory 前，不釋放任何記憶體** (即使查詢結束只需 20MB，仍保持 40MB)。
- 達到 Min Memory 後，進入**動態平衡區**：依負載在 Min~Max 區間申請/釋放。
上限保護
- **絕不超過 Max Memory** (Buffer Pool 範圍)。
- 某些配置 (如 Columnstore、In-Memory OLTP、CLR、Thread Stack) 可能略超出 Max Memory，需預留緩衝。
多應用共存的衝擊與對策
| 場景 | 問題 | 配置對策 |
|---|
| SQL 啟動後，再啟動郵件/ERP 等應用 | 啟動期需大量記憶體，SQL 佔用過多導致等待/失敗 | **Min Memory 設小** (如 0-512MB)，釋放彈性 |
| 同時備份 (SQL + 郵件 + ERP) | 備份高峰期記憶體爭用 | **Max Memory 設保守** (留 2-4GB 給 OS/其他)、錯開備份排程 |
| SQL 負載高峰期 | SQL 需更多記憶體 | Max Memory 設合理上限，動態成長 |
| 其他應用佔 90%+ 記憶體 | SQL 可能餓死 | **Min Memory 設下限** 保障 SQL 基本生存 |
配置方法論：監測 → 分析 → 設定 → 持續微調
- 監測：上線第一年**每月記錄** (前幾月不穩定參考價值低)，重點第 6-12 個月。工具：PerfMon `SQL Server:Buffer Manager\Target Pages / Total Pages`、`Process(sqlservr)\Working Set / Private Bytes`、`Memory\Available MBytes`。
- 分析：繪製記憶體使用曲線，識別：
- SQL 穩態區間 (Min 候選)
- SQL 尖峰區間 (Max 候選)
- 其他應用尖峰時間 (錯開排程)
- 設定：
`Min = 穩態下沿 - 緩衝` (建議偏小，如 512MB-2GB)
`Max = 尖峰上沿 + 緩衝` (建議偏大，但 ≤ 實體 RAM - OS保留 - 其他應用尖峰)
**原則：Min 偏小、Max 偏大、區間寬、彈性足**。
- 微調：應用變更、資料增長、功能啟用後持續監測調整。通常需數月達到最優。
特殊配置場景
- Min = Max (固定記憶體)：
- 專用資料庫伺服器、追求極致穩定、避免動態調整開銷。
- 效能基準測試、排除記憶體變數干擾。
- **不適合**多應用共存環境。
- 超出 Max Memory 的配置：
- Thread Stack (`max worker threads` * 2MB/4MB)、
- Columnstore Object Pool、
- In-Memory OLTP 記憶體優化檔案、
- CLR、Linked Server 驅動、
- 備份緩衝區 (`MAXTRANSFERSIZE` * `BUFFERCOUNT`)。
**實際總佔用 ≈ Max Memory + 500MB-2GB**，規劃實體 RAM 須含此緩衝。
錯開排程：記憶體共存的隱形技巧
- ERP 複雜報表 (庫存採購) → 午夜 00:00 執行，晨間出結果。
- 各系統備份錯峰：SQL 22:00、郵件 23:00、ERP 01:00。
- SQL Agent 作業 `sp_configure 'max worker threads'` 適度限制並發備份執行緒。
結語
Min/Max Server Memory 不是「設定後就忘記」的參數，而是**需持續觀測、隨業務演進微調的動態閥門**。**監測數據驅動決策、Min 偏小 Max 偏大、錯開尖峰排程、預留系統緩衝**——四句口訣，守護多應用共存穩定運行。
