對於高 CXPACKET 等待，我該怎麼辦？
我們的 MS SQL Server 2016 數據庫執行緩慢，我一直在使用 Brent Ozar 的急救箱進行一些初步故障排除。
我看到了大量的 CXPACKET 等待類型，在 17.5 小時的數據樣本中，我們看到 10 個 CPU 的等待時間為 99 小時，即 55.5%！
我希望這裡有人可以確認我們應該關注這個數字並儘快解決它。我們將 MAXDOP 設置為 4，這與 MS 建議準確，但我們的 CTP 設置為 5，我認為需要將其更改為 50。
在我把這些資訊帶給我的老闆之前只是想澄清一下，是的，我是數據庫管理的新手，是的，我正在研究其他等待類型，但這似乎是迄今為止最重要的。
乾杯，
喬什
安裝 SQL Server 2016 SP2
你提到你在 13.0.1745.2。這是 SQL Server 的 RTM 版本，實際上從 1/9/2018 開始不再支持。
另外，如果您安裝 SP2，您將獲得新的 CXCONSUMER 等待類型（請參閱此處了解有關此的大量資訊）。這將“無害”的並行等待與您實際上可以做些什麼的等待分開。這可以幫助您確定 CXPACKET 是否真的是您的伺服器的問題！
查詢調整
查看 Paul Randal 的這篇文章：膝跳等待統計：CXPACKET
在其中，他談到了 CXPACKET 如何成為一種正常的等待類型——如果查詢是並行的，它總是會發生（特別是因為你還沒有 CXCONSUMER 拆分）。他還討論了查詢調整如何成為比調整 MAXDOP 和成本門檻值更有效的解決方案（找出根本原因）：
意外並行的常見情況之一是發生表掃描時您期望較小的索引查找或掃描。
他接著說，索引、統計更新等可以用來消除掃描，因此查詢將不太可能並行。
更改 MAXDOP
如果您確實需要減少 CXPACKET 等待的數量，您可以將 MAXDOP 減少到 2（從目前設置為 4）——但這可能會引入其他問題。當然，如果您已經通過性能測試確定 4 對您的系統來說是一個不錯的設置，請忽略該建議。
提高並行性的成本門檻值
另一種選擇是增加此值，以防止某些查詢完全並行。我看到很多建議建議從50開始，而不是預設的5（範例）。
您的 SQL Server 正在執行什麼類型的工作負載、高度 OLTP（如果有的話，並行性會少得多）或大型繁重的 ETL 類型查詢（並行性將是有益的）——現實很可能是兩者的混合。
如果它需要並行性，那麼 MAXDOP 4 聽起來很合理，但預設成本門檻值太低了，任何超過 5 的查詢都可能使用並行計劃，所以這肯定是一個改變的候選（50 是被廣泛認為的最佳起點）。
一旦了解了工作負載並正確配置了伺服器並行性，您就可以開始分析查詢了。它們是因為需要而並行，還是因為需要使用索引等進行調整而成本高？