問題在SQL Server存儲過程的參數

我記得讀了一段時間後，它隨機SQL Server可以減緩和/或採取一個愚蠢長的時間來執行存儲過程時，它是這樣寫的：問題在SQL Server存儲過程的參數

CREATE PROCEDURE spMyExampleProc 
(
    @myParameterINT 
) 
AS 
BEGIN 

    SELECT something FROM myTable WHERE myColumn = @myParameter 

END

解決這個錯誤的方法是做到這一點：

CREATE PROCEDURE spMyExampleProc 
(
    @myParameterINT 
) 
AS 
BEGIN 
    DECLARE @newParameter INT 
    SET @newParameter = @myParameter 

    SELECT something FROM myTable WHERE myColumn = @newParameter 
END

現在的問題是，首先是它不好的做法，遵循我的所有存儲過程的第二個例子嗎？這看起來像是一個可以在很少工作的情況下很容易防止的bug，但是這樣做會有什麼缺點，如果是的話，爲什麼？

當我讀到這個問題時，相同的過程需要不同的時間來執行取決於參數的值，如果任何人都可以告訴我這個問題被稱爲/爲什麼會發生，我會非常感激，我似乎無法找到任何地方的帖子鏈接，這似乎是我們公司可能發生的問題。

來源

2011-12-13 Purplegoldfish

我從來沒有聽說過一個問題，但如果是這樣的話，可能是由於存儲過程的預編譯。也許在查詢中使用參數會阻止優化存儲過程。 – Russell

@Russell我有同樣的意見。 –

@Russell它不是我曾經聽說過的問題，我確實認爲這是由於預編譯而引起的，但我不記得確切的細節。我只是問現在，因爲我移動了大量的查詢到存儲過程中，它似乎是一個可以很容易地阻止，即使它是一個罕見的bug工作很少 – Purplegoldfish

的問題是「parameter sniffing」（SO搜索）
與@newParameter該模式被稱爲「parameter masking」（也因此search）

你總是可以使用這種屏蔽模式，但它並不總是需要的。例如，一個簡單的按唯一鍵選擇，沒有子表或其他過濾器應該每次都按預期行事。

由於SQL Server 2008，您還可以使用OPTIMISE FOR UNKNOWN (SO)。另見Alternative to using local variables in a where clause和Experience with when to use OPTIMIZE FOR UNKNOWN

來源

2011-12-13 10:16:33 gbn

真棒回答非常感謝，我會檢查出這些鏈接，並將其標記爲可以接受。 – Purplegoldfish

問題在SQL Server存儲過程的參數

回答

相關問題