隨著列儲存索引的出現，“並行成本門檻值”的設置指南是否發生了變化？
首先，我不是在問什麼。我不是在問我的設置應該是什麼。
許多人建議將值提高到預設值以上，我當然理解為什麼基於 B-Tree 的查詢會出現這種情況。但我一直在閱讀記憶體中聚集列儲存索引的（幾乎）線性可伸縮性，我想知道將成本門檻值設置得太高是否會導致 SQL Server 餓死基於列儲存的 CPU 核心查詢。
所以問題是這樣的：當考慮到“並行性的成本門檻值”時，SQL Server 是否會以不同的方式處理列儲存索引，這是否會導致我改變我對初始設置應該是什麼的決定？
除了成本門檻值設置之外，SQL Server 似乎根據您的 SQL Server 版本（2012 與 2014）甚至表中的數據類型，對列儲存索引的並行處理方式有所不同。
我將從Joe Chang 的文章 benchmarking decimal vs float datatypes開始，並閱讀該文章的評論。如果您想為您的系統獲得完全正確的 MAXDOP 和 Cost Threshold for Parallelism 設置，您需要執行 Joe 在他的文章中所做的詳細測試級別，這需要大量工作。因此，我將首先關注您系統的主要瓶頸 - 使用等待統計資訊來確保並行性或 CPU 壓力對您來說是個問題，然後從調整最佔用 CPU 的查詢開始，而不是更改系統設置。
TL;DR：您讀到的建議的初始設置 50仍然是一個不錯的起點。每個 NUMA 節點 1 個物理核心的 MAXDOP 對像我們這樣同時服務於 OLTP 和 OLAP 工作負載的伺服器來說是一個很好的設置。
推論：SQL Server 確實非常擅長它的功能。
我對這個設置的主要擔心是我是否會禁止在基於聚集列儲存的索引上並行執行應該是非常短的查詢。設置為 50 是否會導致不到 1 秒的查詢花費更多時間？由於列儲存索引在 CPU 上的擴展性非常好，是否會忽略“並行成本門檻值”設置？
- 問：SQL Server 是否會遵守列儲存索引的“並行成本門檻值”？
- 答：是的。 當配置了一個荒謬的 30,000 設置時，列儲存索引的並行性對我的工作負載有效地被禁用。嘗試其他一些仍然淫穢的值 (1,500) 會抑制名義上需要大約一秒鐘才能執行的工作負載的並行性，但名義上執行大約 10 秒或更長時間的查詢會顯示並行執行計劃。
- 問：在某些清單中指定的預設設置 50 是否是一個不會抑制基於列儲存的查詢的並行性的安全值？
- A:是的，而且很可能。即使將值提升到 500，仍然允許基於簡單、短（亞秒級）列儲存的查詢的並行性。
關於我的伺服器、工作負載和結果：
- 2 個 Xeon E2650v2，（2 個 NUMA 節點，12 個物理核心，24 個 HT 執行緒），384 GB RAM
- MAXDOP 配置為 6（每個 NUMA 節點 6 個物理核心）
- SQL Server 2014 企業版 CU4
- 在 6 個分區中測試 111,000,000 行聚集列儲存索引（按年份）
測試了兩個工作負載：
SELECT COUNT(DISTINCT <low cardinality column>) FROM table;SELECT COUNT(DISTINCT <high cardinality column>) FROM table;高基數列的查詢在超過 1500 的門檻值處花費了 84 秒（經過），在低於該數字的門檻值處花費了大約 14 秒（經過）。低基數列的查詢在門檻值 500 及以下花費了大約 250 毫秒（經過），在門檻值超過 1500 時花費了 18 秒（經過）。（我沒有試圖衡量它切換計劃的確切時間點。） ，當並行性被禁止時，低基數查詢的總 CPU 時間急劇增加；可能伺服器停止對此查詢使用批處理模式。
呵呵，最終執行測試會導致更多問題，但這都是部落格的素材，超出了這個問題的範圍。