重新編譯長時間運行的查詢是一種好習慣

我有一些長時間運行（幾個小時）的存儲過程，其中包含查詢，該查詢轉到包含分佈式環境中數百萬條記錄的表。這些存儲過程採用日期參數並根據該日期參數篩選這些表。重新編譯長時間運行的查詢是一種好習慣

我一直在想，由於SQL Server的參數嗅探功能，在我第一次調用存儲過程時，查詢執行計劃將根據該特定日期進行緩存，任何未來調用都將使用該函數確切的計劃。我認爲，由於創建執行計劃只需要幾秒鐘，爲什麼我不會在長時間運行的查詢中使用RECOMPILE選項，對不對？它有沒有我錯過的缺點？

來源

2017-08-24 sotn

如果每分鐘有1000個用戶調用該sp，則重新編譯不是您想要的。如果您在DWH環境中每天執行一次sp，重新編譯只是有益的 – sepupic

重新編譯不太可能是有害的，但它可能不會對您有太大的好處。例如，如果您忽略維護表格統計信息（並且這對於大型表格很容易實現，因爲自動更新的閾值只會增加），您每次都會得到同樣糟糕的執行計劃。或者相反，第一個計劃可能是ace，因爲你查詢的範圍*有*正確的統計數據，然後是'RECOMPILE'命中，必須掃描一個沒有統計數據的範圍和你的表現坦克。好的工作打破了它，英雄。 –

@sepupic即使1000個用戶會打電話，一個用戶將等待1個小時，另一個用戶將等待4個小時（可能是因爲因緩存的「壞」查詢執行計劃而導致一些索引未被使用）。在我看來，喜歡在CPU使用率和（可能的）很長的等待時間之間進行權衡。 – sotn

如果查詢應該在你可接受的性能極限運行，並且懷疑參數嗅探是原因，我建議你添加的重新編譯提示查詢..

此外，如果查詢是存儲過程的一部分，而不是重新編譯整個PROC，你也可以做一個語句級重新編譯像

create proc procname 
(
@a int 
) 
as 
select * from table where [email protected] 
option(recompile) 

--no recompile here 
select * from table t1 
join 
t2 on t1.id=t2.id 
end

另外提醒，重新編譯查詢將花費you.But從Paul White

報價210
每次執行都需要支付計劃編制費用，但改進後的計劃質量通常會多次支付這筆費用。在2016年

查詢商店可以幫助你跟蹤這個問題，還存儲查詢過time..you計劃就能看出表現糟糕..

，如果你不是在2016年，威廉·德金已經開發open query store的版本（2008-2014）的作品或多或少相同，並幫助您在troubleshootng問題

延伸閱讀：
Parameter Sniffing, Embedding, and the RECOMPILE Options

來源

2017-08-24 12:23:19 TheGameiswar

重新編譯長時間運行的查詢是一種好習慣

回答

相關問題