在 SQL Server 的 VM 上共享 CPU 是否正常？
我們的 IT 在包含其他 VM 的大型 VMWare 盒子上將 SQL Server 設置為 VM。CPU 設置為共享。因此，任何可能需要多個 CPU 的查詢所花費的時間都比我將其限制為單個 CPU 的時間長 30 倍。例子：
SELECT TOP 2000 lwa.Message INTO #foo FROM dbo.LogWidgetsAPI lwa (NOLOCK) ORDER BY lwa.TimeStamp對比
SELECT TOP 2000 lwa.Message INTO #foo FROM dbo.LogWidgetsAPI lwa (NOLOCK) ORDER BY lwa.TimeStamp OPTION (MAXDOP 1) ------------- Force it to run on a single CPU第一個範例使用並行性，大約需要 30 秒左右。第二個強制使用單個 CPU 並花費 20 毫秒。
注意：執行單 CPU 查詢後，我返回執行多 CPU 查詢，時間和計劃是相同的 - 所以我認為問題與“冷記憶體”與“熱記憶體”無關
所以我的理論是，因為第一個查詢使用多個 CPU，它必須等到所有有問題的 CPU 都空閒，因此它只是等待。
所以我的問題。SQL Server VM 應該有專用 CPU 還是共享 CPU 是正常的？
在 SQL Server 的 VM 上共享 CPU 是否正常？
是的，這很常見。很多時候，VM 用於將大量 SQL Server（尤其是那些沒有極端性能要求的 SQL Server）整合到一台主機上。這可以節省許可成本，因為 SQL Server 可以在主機級別獲得許可。
這是個好主意嗎？我的意思是，這在很大程度上取決於VM的超額訂閱量以及工作負載的 CPU 密集程度。
看兩個執行計劃的截圖，除了並行度外，基本相同。並行計劃中的一個問題區域是“Top”操作員所在的串列區域：
將所有行放在一個執行緒上，然後將它們重新分配以進行並行插入會產生一些成本。不過，我不希望成本為 30 秒。
所以我的理論是，因為第一個查詢使用多個 CPU，它必須等到所有有問題的 CPU 都空閒，因此它只是等待。
不，這不是 SQL Server 中並行性的工作方式。根據不同 CPU 的繁忙程度，掃描計劃右上角的聚集索引的執行緒可能會執行非常不均勻的工作級別。
現在，如果這個 SQL Server 實例太忙以至於所有可用執行緒都被用於其他查詢，那麼並行查詢可能正在等待
THREADPOOL。這讓我想到了下一點：並行查詢很可能正在等待某些資源。我將首先查看 SSMS 中執行計劃的“WaitStats”部分：
這將位於計劃中最左側運算符的“屬性”視窗中。例如，
SOS_SCHEDULER_YIELD在這種情況下，一個非常高的值可能表明此 SQL Server 實例沒有啟動主機 CPU。Jonathan Kehayias 在這裡有一篇關於該主題的非常好的文章：CPU 就緒對 SOS_SCHEDULER_YIELD 的影響
您還可以比較兩個查詢中經過的時間與 CPU 時間的比率。這些數字在同一個屬性視窗中：
如果兩個查詢之間的比率顯著不同，這是並行查詢正在等待某些資源的另一個跡象。
如果您可以訪問主機/虛擬化，您可以直接在那裡查看統計資訊，看看客人是否在等待很長時間才能在 CPU 上安排。Jonathan 在這裡有另一篇關於此的文章，專門針對 VMWare：VMware 中的 CPU 就緒時間以及如何解釋其真正含義
