這是在MS-SQL的錯誤

我想知道，如果下面是我們的設置錯誤或MS-SQL的錯誤：這是在MS-SQL的錯誤

如果我們運行有三個參數一定的存儲prodecure約需3分鐘。

CREATE PROCEDURE [dbo].[ourProcedure] 
    @param1  int, 
    @param2  int, 
    @param3  dateTime 
AS 
BEGIN...

如果我們運行相同的程序，但在創建中我們已經創建了參數的本地副本，它只需要11秒！

CREATE PROCEDURE [dbo].[ourProcedure] 
    @param1_x int, 
    @param2_x int, 
    @param3_x dateTime 
AS 
BEGIN 

DECLARE @param1 int 
DECLARE @param2 int 
DECLARE @param3 dateTime 

@param1 = @param1_x 
@param2 = @param2_x 
@param3 = @param3_x 
...

有人可以告訴我爲什麼嗎？爲什麼SQL不處理像C＃這樣的參數？

來源

2014-04-09 Joakim M

你能展示其餘的SP嗎？或者更好：比較兩個變體之間的查詢計劃。我認爲它與某種參數嗅探有關。這不是一個「sql性能」問題（如在解釋器中），但我認爲這是針對您生成的某些選擇的不同查詢計劃。 – TomTom

不，這不能成爲SP緩慢的原因。可能是SP中的查詢。發佈查詢。 – Rahul

「SP慢」咦？你讀過我的問題了嗎？唯一不同於SP的是我添加了複製參數的局部變量。 –

這就是通常所說的「參數嗅探」。問題在於SQL Server優化器使用參數的值和內部統計信息來分配值，以估算傳遞給過程的值的基數，並生成執行計劃。但是，由於許多原因，這可能會出錯。還有一點需要指出，執行計劃是被緩存的，所以程序在第一次執行時就被優化了。如果用於優化程序的參數與當前的程序不同，則可能導致性能不佳。

優化程序不能使用變量值執行相同操作，因爲變量分配是正在優化且未預先知道的同一批次的一部分。在這種情況下，它使用啓發式和平均值，這可能導致不同的執行計劃。

總之，您有兩個不同的執行計劃，第一個也可能針對不同的參數值進行了優化。

來源

2014-04-09 08:13:20 dean

不會重新編譯並清除緩存解決此問題？（注意：我們沒有成功嘗試）至少你會在第一次運行SP時獲得相同的性能？ –

重新編譯只會解決緩存計劃問題，但（由於第二個過程中使用的變量），您仍然會得到兩個不同的計劃。不能說爲什麼第一個計劃沒有看執行計劃而效率不高（我不認爲它只是它的圖片） – dean

@JoakimM如果你在SP的查詢中添加了「選項（重新編譯）」，你應該得到相同的在這兩種情況下。從外觀上看，你應該在兩種情況下都得到不好的計劃。另一件要測試的事情是在查詢中使用'option（未知優化）'。那麼你仍然應該得到相同的計劃，但這將是一個很好的計劃，因爲你正在優化而不使用參數中的已知值。 –

這是在MS-SQL的錯誤

回答

相關問題