2015-12-16 41 views
5

我有一個查詢正在放入存儲過程。當我使用局部變量運行查詢時,查詢需要1秒鐘才能運行。當我將相同的查詢放入存儲過程並調用SP時,大約需要2分鐘才能運行。將SQL Server查詢放入存儲過程時運行速度很慢

從SO以前的問題,我認爲它可能給參數嗅探有關。當我在我的SP中聲明瞭局部變量之前就已經有了這個問題,然後在整個過程中使用了局部變量。這在過去有效,但在這種情況下似乎沒有幫助我。

我現在有

CREATE PROCEDURE dbo.ProcedureName 

    @DIV VARCHAR(4), 
    @STD VARCHAR(1), -- S or N 
    @scen varchar(20) 
AS 
BEGIN 

    DECLARE 
     @DIV_copy VARCHAR(4), 
     @STD_copy VARCHAR(1), 
     @scen_copy varchar(20); 
    SELECT 
     @DIV_copy = @DIV, 
     @STD_copy = @STD, 
     @scen_copy = @scen; 

我也嘗試添加WITH RECOMPILE喜歡在我的SP中,像這樣的結束使

CREATE PROCEDURE dbo.ProcedureName 

    @DIV VARCHAR(4), 
    @STD VARCHAR(1), -- S or N 
    @scen varchar(20) 

WITH RECOMPILE 
AS 
BEGIN 

    DECLARE 
     @DIV_copy VARCHAR(4), 
     @STD_copy VARCHAR(1), 
     @scen_copy varchar(20); 
    SELECT 
     @DIV_copy = @DIV, 
     @STD_copy = @STD, 
     @scen_copy = @scen; 

此外,我曾嘗試加入OPTION(RECOMPILE)

SELECT * 
    FROM #Output 

OPTION(RECOMPILE) 

END 
GO 

我也嘗試使用:

OPTION(OPTIMIZE FOR UNKNOWN) 

除了:

OPTION(QUERYTRACEON 4136) 

這個選項,我沒有查詢跟蹤相應的權限。上述

無5個修復的出現來解決問題作爲存儲過程2分鐘,2分鐘,對於需要的存儲過程的外側1或2秒的相同查詢到30秒之間仍然需要的任何地方。

這些修補程序都從這篇文章「Different Approaches to Correct SQL Server Parameter Sniffing

來有沒有人有類似的問題?感謝您的時間!

的SQL Server 2008R2

+0

它聽起來像參數嗅探,我沒有任何其他想法它可能是。你可以查看這篇文章,看看它是否提供了你還沒有嘗試過的任何附加解決方案:http://www.sommarskog.se/query-plan-mysteries.html –

+0

'我嘗試添加OPTION(RECOMPILE)at我的SP'結束 - 它應該放在違規查詢之後。但是如果「重新編譯」不起作用,我懷疑這個更正會。 –

+0

我有完全相同的症狀,並創建params的本地副本始終解決它。唯一的區別是我總是使用SET語句而不是SELECT語句將值複製到局部變量中。 –

回答

0

可惜我沒弄明白爲什麼同樣準確的查詢有這麼多的麻煩放在一個存儲過程中時相比,單獨的SQL語句。

作爲「解決方法」我花了一些時間在SP內部優化我的查詢。我意識到我加入的一張表非常大(數百萬行),所以我所做的就是從大表中獲取相關數據並創建一個臨時表來保存它,然後加入到(很多)較小的臨時表中這似乎是訣竅。 SP現在在3-4秒內執行。

我還是有點新,所以我學習了很多基礎知識以外的SQL語句。讓我們來提醒您仔細查看您的疑問,但通常還有改進的空間。這感覺有點像透明膠帶和回形針,但我的問題解決了。

謝謝大家對您的輸入。

+0

而不是臨時表格,您可能會通過向與匹配條件匹配的大表添加索引來做更好的工作。 –

+0

是的,但我沒有權限這麼做,儘管我可能會問我們的DBA團隊。 – Soulfire

相關問題