TempDB 檔案數不必等於 CPU 核心數：從 1:1 迷思到動態調整指導原則

迷思來源

早期 Microsoft 官方文件與大量部落文建議「TempDB 檔案數 = CPU 核心數（1:1）」。但這源自 SQL CAT 團隊面對極大型客戶的擴展性測試，非通用法則。

何時需要增加 TempDB 檔案？

只有當觀測到 PAGELATCH_* 等待（配置頁 GAM/SGAM/PFS 爭用） 時，才考慮增加檔案。若為 PAGEIOLATCH 則是 I/O 子系統瓶頸，增加檔案無效。

版本演進與建議比例

• SQL 2000： 嚴格 1:1。
• SQL 2005/2008： 優化配置演算法，建議檔案數 : 核心數 = 1:2 或 1:4。
• Bob Ward (SQL PASS 2011) 新公式： 核心數 ≤ 8 時 1:1；> 8 時固定 8 個檔案，出現閂鎖爭用每次加 4 個。

檔案過多的負面效應

1. 循環配置同步開銷： 單一檔案組包含大量檔案時，配置執行緒需額外同步，反而降低效能。
2. 檔案大小不均導致熱點： 自動成長集中於單一檔案，造成 I/O 熱點。
3. Lazy Writer 隨機 I/O： TempDB Checkpoint 不寫回髒頁，依賴 Lazy Writer，多檔案可能導致隨機讀寫惡化。

指導原則

預設從 1/2/4/8 個檔案起步（視核心數），監控 sys.dm_os_wait_stats 中的 PAGELATCH 等待，僅在確認配置爭用時逐步增加。 在擴展性與單查詢效能間取得平衡。

儲存配置建議

TempDB 檔案無需分散多個儲存裝置。PAGELATCH 爭用分散儲存無效；PAGEIOLATCH 才考慮移動整個 TempDB 至更快儲存，而非只是增加單一檔案。