雜湊匹配溢出和密鑰查找導致主要性能問題
我已經更新了所有索引的統計資訊，但是這個查詢仍然需要將近 40 秒才能執行。我需要它在 20 歲以下。我不是 DBA，而且在閱讀執行計劃方面非常陌生。我將不勝感激任何可以幫助我提高此查詢性能的幫助。
您的查詢僅使用大約 2 秒的 CPU 時間。您可以在執行計劃的根節點中查看。它花了大約 30 秒等待各種事情。
該等待時間中的 7915 毫秒用於ASYNC_NETWORK_IO等待類型。當 SQL Server 準備好向客戶端發送更多數據但客戶端尚未指示它已準備好接收更多數據時，就會出現這種等待類型。在 SSMS 結果網格中查看大型結果集時，通常會看到這種情況。如果您在應用程序中看到相同類型的等待，請查看處理返回的結果集的程式碼，並檢查是否返回了不必要的列。否則，您可能會發現丟棄結果集以更準確地衡量查詢性能很有幫助。照原樣，您在 20 秒的目標中損失了 8 秒。
您使用這些散列連接溢出少量數據，但查詢執行會因此顯著減慢。我可以在本地機器上安排類似的結果：
溢出和加入對我來說大約需要 0.289 秒。這比您的伺服器上發生的速度快大約 33 倍。我了解您可能無法控制您使用的雲平台。但是，手動調整查詢的時間匯需要與其他解決方案進行平衡。該查詢僅花費 2 秒的 CPU 時間。如果你有更好的硬體，那麼它可以在 20 秒內輕鬆完成，無需更改程式碼。坦率地說，如果有人給我一個性能和你看到的一樣差的虛擬機，我會拒絕使用它。
如果您無法獲得更好的硬體，那麼您應該能夠通過添加
MIN_GRANT_PERCENT = 99查詢提示來測試查詢性能而不會溢出。如果性能顯著提高，則嘗試改進進入散列連接的基數估計。您看到 tempdb 溢出的原因是記憶體授予太小，因為實際行數大約是估計行數的 20 倍：
這個複雜的謂詞可能會導致問題：
@Now BETWEEN OPL.StartDateUTC AND COALESCE(DATEADD(MILLISECOND, -3, CAST(CAST(DATEADD(DAY, 1, OPL.EndDateUTC) AS DATE) AS DATETIME)), DATEADD(MILLISECOND, -3, CAST(CAST(DATEADD(DAY, 1, @Now) AS DATE) AS DATETIME)))要嘗試的一件事是將連接
Organization和OrganizationProductLanguage表的結果放入臨時表中。使用臨時表，查詢優化器將知道您從該步驟獲得 12 行而不是 1.41312。僅此一項就足以增加估計值以避免 tempdb 溢出。如果在修復 tempdb 溢出後性能仍然無法接受，則嘗試通過在已使用的非聚集索引中包含其他列來擺脫一些關鍵查找。我預計大部分影響來自將
ActivatedDateUTC和InactivatedDateUTC列添加到[ProductAsset].[UX_ProductAsset]. 添加DataValue到[AssetCacheData].[IX_AssetCacheData]. 這可能會比通常預期的更多地改進查詢執行時間，因為該伺服器對 I/O 施加瞭如此大的懲罰。
