並行查詢透過多執行緒同時處理單一查詢作業，發揮多 CPU 伺服器效能。SQL Server 查詢最佳化器自動決定是否並行、平行度與執行計畫，DBA 需理解其決策邏輯與硬體制約，才能在設計與調優時事半功倍。
並行查詢三階段決策流程
階段一：是否並行 — 最佳化器成本評估
查詢最佳化器在產生執行計畫時評估：
- 序列計畫成本是否已足夠低，無須並行。
- 是否包含無法並行的純量/關聯運算子（如某些 CLR 函數、特定資料行存取模式）。
- 並行計畫預估成本是否低於序列計畫。
若決定並行，最佳化器會在計畫樹插入 Exchange 運算子（Gather/Repartition/Distribute Streams）協調執行緒間資料流動。
階段二：決定平行度 (DOP)
- 最大平行度： 伺服器層級設定（
sp_configure 'max degree of parallelism'），上限為邏輯 CPU 核心數。
- 實際平行度： 執行階段依計畫複雜度、可用執行緒、記憶體授予動態決定，不超過最大平行度。
- 查詢提示覆蓋：
OPTION (MAXDOP n) 可針對單一查詢指定 DOP，覆蓋伺服器預設值。
階段三：執行與動態調整
執行緒池不足時，引擎會自動降低 DOP 甚至退回序列計畫，避免資源耗盡導致系統停擺。
硬體與資源限制 — 並行查詢的天花板
- 多 CPU 強制條件： 單 CPU 機器永不觸發並行查詢。
- 執行緒可用性： 每個並行作業需額外執行緒，高 DOP 消耗更多 Worker Thread，若
max worker threads 耗盡將強制降級。
- 記憶體授予： 並行查詢需較大記憶體授予（排序、雜湊、交換緩衝），記憶體壓力大時會限制並行度。
- NUMA 架構： 跨 NUMA 節點存取遠端記憶體延遲高，SQL Server 2005+ 具 NUMA 感知排程，但不當配置仍會拖累並行效能。
DBA 可行動建議
- 依工作負載類型設定伺服器級
MAXDOP（OLTP 建議 4~8，DW 可更高）。
- 關鍵長時間查詢使用
OPTION (MAXDOP n) 微調。
- 監控
sys.dm_os_wait_stats 中 CXPACKET、THREADPOOL 等待，判斷並行壓力。
- 規劃硬體採購時，優先保證 CPU 核心數、記憶體頻寬與 NUMA 區域平衡。
