為什麼 MAXDOP = 0 會導致高 CXPACKET 等待時間？
在並行查詢執行期間（是否並行由並行的成本門檻值決定）MAXDOP 限制每個請求的任務數。
假設並行性的成本門檻值較低，則會導致更小的查詢並行工作。
當 MAXDOP 設置為 0 時，是什麼讓已完成工作的處理器等待（導致高 CXPACKET 等待時間）。他們能不能不接下一份工作而不只是等待？
是什麼讓處理器在完成工作後等待？
來自https://www.brentozar.com/archive/2013/08/what-is-the-cxpacket-wait-type-and-how-do-you-reduce-it/
這本身並不是一個真正的瓶頸——學生們可以出去做其他工作——但他們喜歡抱怨他們不得不等著慢孩子。
抱怨的是 CXPACKET – Class eXchange Packets。全班都在交包，抱怨孩子們反應遲鈍。
這不是一個獨特的問題
MAXDOP = 0，而是更容易在並行執行緒之間發生過度等待，並且當查詢中的給定程序集有更多執行緒用於並行處理時，成本會增加。當MAXDOP = 0查詢計劃中的操作子集並行時，可以使用多少執行緒沒有限制（最多分配給伺服器的 CPU 核心數）。在您連結的 Brent Ozar 文章中，什麼是 CXPACKET 等待類型，以及如何減少它？，他提到了 Microsoft 的建議是如何不設置
MAXDOP高於 8，因為當使用超過 8 個執行緒時，查詢計劃中的並行性回報通常會遞減。這可能會導致並行化執行緒中的工作分佈不均勻，這將導致一些執行緒無所事事地等待，而其他執行大部分工作的執行緒仍在處理中。CKPACKET這是過度發生等待的一種方式。即使工作是均勻分佈的，它也可能足夠小，以至於太多的執行緒仍然比少數幾個執行緒更有效，例如 8 個執行緒可能與 4 個執行緒一樣快地處理工作，然後有額外的成本來旋轉那些執行緒以及協調執行緒從 8 個執行緒（Brent Ozar 的文章中的“學生交作業”部分）消耗回來的工作，這對於 4 個執行緒來說會更快/成本更少。
所以同樣，這不是
MAXDOP = 0問題或解決方案的任何特定價值MAXDOP，而只是確保您的查詢和伺服器根據執行在其上的典型工作負載進行適當配置。並且隨著更多核心被允許用於特定查詢中的並行性，並行性產生過多成本的可能性也會增加。有關
CXPACKET等待如何工作的詳細資訊，請參閱SQL Server 中的 CXPACKET 等待類型疑難解答
你寫了：
是什麼讓處理器在完成工作後等待？
不是處理器在等待，也不是程序在等待，而是並行的物理操作在等待最後一個執行緒返回其數據。
如果您有一個執行緒讀取數據，那麼您將進行這樣的串列讀取：
1 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ^ ^ | | Start End --> (t)80 條記錄的範例
現在，如果查詢優化器由於 CTFP（並行成本門檻值）和 MAXDOP 設置為 0 而決定並行，那麼在具有四個（為了簡化）核心的伺服器中，該過程將理想地通過索引到四個處理器：
1 xxxxxxxxxxxxxxxxxxxxxx 2 xxxxxxxxxxxxxxxxxxxxxx 3 xxxxxxxxxxxxxxxxxxxxxx 4 xxxxxxxxxxxxxxxxxxxxxx ^ ^ | | Start End --> (t)如果查詢可以並行執行，則檢索 80 條記錄的過程的持續時間會更短。在這樣做時，查詢引擎假設數據分佈均勻。這是基於最新的統計數據。
在某些情況下，統計數據可能會出現偏差（不是最新的），並且工作負載分佈不均。根據所涉及的 WHERE 子句和表以及其他因素，您可能會遇到如下情況：
1 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (40 rows) 2 x ( 1 row) 3 xxxxxxxxxxxxxxxxxxxxx (19 rows) 4 xxxxxxxxxxxxxxxxxxxxxx (20 rows) ^ ^ | | Start End --> (t)如您所見，檢索數據所需的時間比統計數據是最新的並且檢索數據的負載將平均分佈的情況要長。它仍然比串列檢索快，但其他執行緒（2、3、4）必須等到執行緒 1 完成檢索其數據塊。
這些等待是您可能正在觀察的 CXPACKETS 和 CXCONSUMER。CXPACKETS（並行檢索數據）還不錯。當檢索的日期線上程之間均勻分佈時，它們甚至會發生，但是你有更少的 CXCONSUMER（等待並行數據）。
回答你的問題
是什麼讓處理器在完成工作後等待？
它不是在等待。它在表演。