這是在Windows SQL Server羣集上。Microsoft SQL Server:錯誤的查詢執行計劃耗時太長
查詢來自第三方應用程序,所以我無法永久修改查詢。
查詢:
DECLARE @FromBrCode INT = 1001
DECLARE @ToBrCode INT = 1637
DECLARE @Cdate DATE = '31-mar-2017'
SELECT
a.PrdCd, a.Name, SUM(b.Balance4) as Balance
FROM
D009021 a, D010014 b
WHERE
a.PrdCd = LTRIM(RTRIM(SUBSTRING(b.PrdAcctId, 1, 8)))
AND substring(b.PrdAcctId, 9, 24) = '000000000000000000000000'
AND a.LBrCode = b.LBrCode
AND a.LBrCode BETWEEN @FromBrCode AND @ToBrCode
AND b.CblDate = (SELECT MAX(c.CblDate)
FROM D010014 c
WHERE c.PrdAcctId = b.PrdAcctId
AND c.LBrCode = b.LBrCode
AND c.CblDate <= @Cdate)
GROUP BY
a.PrdCd, a.Name
HAVING
SUM(b.Balance4) <> 0
ORDER BY
a.PrdCd
這種特殊的查詢花費太多的時間來完成執行。同一個問題發生在不同的SQL Server上。
沒有發現表鎖,查詢運行時處理器和內存使用情況正常。
正常「選擇頂1000」兩個表中所做的工作,並表示這兩個表(D009021,D010014)
重新編制在瞬間輸出和重建/更新統計數據,但問題並沒有解決(D009021,D010014)
同樣的查詢工作,如果我們減少分支的數量,但慢慢地
(
DECLARE @FromBrCode INT =1001
DECLARE @ToBrCode INT =1001
)
同樣的查詢工作更快給予2分鐘內輸出,如果我們更換任何一個變量,直接使用值
AND a.LBrCode BETWEEN @FromBrCode AND @ToBrCode
改爲
AND a.LBrCode BETWEEN 1001 AND @ToBrCode
同樣的查詢工作更快,2分鐘內讓輸出,如果我們在結尾處添加「選項(重新編譯)」
我試圖清理緩存查詢執行計劃並優化新的但問題仍然存在
發現查詢估計計劃和實際執行計劃不同(請參見屏幕截圖)
你爲什麼不只是讓'OPTION(RECOMPILE)'永久的嗎?對於可能看到參數值的選擇性差異很大的查詢,沒有任何問題。 –
另外,您最後一次重建統計信息的時間是?或者這就是你在步驟5中「重建」的含義? –
該查詢來自另一個應用程序,我不能修改。重建/更新統計信息沒有解決問題 – Sumanta