處理 CXPACKET 等待 - 設置並行成本門檻值
作為我之前關於對 Sharepoint 站點進行性能故障排除的問題的後續，我想知道是否可以對 CXPACKET 等待做些什麼。
我知道下意識的解決方案是通過將 MAXDOP 設置為 1 來關閉所有並行性 - 聽起來是個壞主意。但另一個想法是在並行性開始之前提高成本門檻值。執行計劃成本的預設值 5 相當低。
所以我想知道是否已經編寫了一個查詢，可以找到執行計劃成本最高的查詢（我知道你可以找到執行時間最長的查詢等等 - 但是執行計劃成本是否可以在某處檢索，也是？），這也會告訴我這樣的查詢是否已並行執行。
有沒有人手頭有這樣的腳本，或者可以指出相關 DMV、DMF 或其他系統目錄視圖的方向來找出這個？
CXPACKET從來都不是原因；它受到了所有的責備，但它總是其他事情的症狀。您需要在行動中捕捉這些查詢並弄清楚“其他東西”是什麼。它可能因查詢而異，並且完全關閉並行性 - 正如您所建議的那樣 - 在大多數情況下是不必要的過度殺傷。但它通常是最少的工作量，這就是為什麼它是如此普遍的“修復”。如果您可以獲得似乎導致高 CXPACKET 等待的查詢的實際計劃，請將其載入到SentryOne Plan Explorer中。這通常是有原因的。我們展示了哪些並行操作導致了執行緒傾斜，您可以輕鬆地將其與關閉的估計相關聯（我們突出顯示估計至少偏離某個門檻值的操作）。通常，潛在的問題是非常糟糕/過時（或不可用）的統計數據。
不幸的是，您會在 sys.dm_exec_cached_plans 中找到估計的計劃。他們不會告訴您計劃在實際使用時是否並行，因為實際計劃不是記憶體的內容。在某些情況下，您希望看到同一查詢的串列和並行計劃；這不是 SQL Server 處理可能在執行時並行的並行計劃情況的方式。（這裡有很多關於這方面的資訊。）