Managment Studio和TableAdapter之間存儲過程的執行時間差異很大

如何通過Management Studio在10秒內運行存儲的程序，但是通過TableAdapter爲同一輸入需要15分鐘？這是可重複的，這意味着我已經在每個環境中至少運行了三次，Management Studio的速度始終快了近100倍。Managment Studio和TableAdapter之間存儲過程的執行時間差異很大

我使用.NET 2.0和SQL Server 2000

在SQL Server Management，我在執行這樣的：

EXEC [dbo].[uspMovesReportByRouteStep] 
    @RouteStep = 12000, 
    @RangeBegin = N'12/28/08', 
    @RangeEnd = N'1/18/9'

在TableAdapter的，我使用的是StoredProcedureCommandType和dbo.uspMovesReportByRouteStep爲CommandText。我從ASP.NET頁面調用表格適配器，但如果我也嘗試在本地「預覽數據」，則會在30秒內超時。

提供存儲過程是不現實的，因爲它存在超過100行的長度，並且依賴於相同數據庫和其他數據庫上的許多其他UDF和視圖。

所有其他存儲過程似乎使用任一方法在大約相同的時間運行。這怎麼可能？

來源

2009-01-16 recursive

這很可能是由於'參數嗅探'和緩存的查詢計劃不適合您調用的參數的特定值。這是如何發生的？那麼，你第一次用一組值來調用一個SP，一個查詢計劃將被生成，參數化和緩存。如果使用另一組參數值再次調用SP，該參數值會導致不同的查詢計劃，但它使用緩存的查詢計劃，那麼性能可能會受到影響。

這通常是因爲統計數據過期。您可以通過將預計執行計劃與實際執行計劃進行比較來確定是否屬於這種情況;如果不同，那麼統計數據很可能會過時。

我會先嚐試重建數據庫的索引，或者至少統計數據已更新（詢問您的DBA）。重建索引的一種方式（應在SQL Server上的所有版本）：

exec sp_msforeachtable "dbcc dbreindex ('?')"

如果它仍然是一個問題，請嘗試暫時將聲明WITH RECOMPILE存儲過程的定義。如果問題消失，那麼看看使用OPTIMIZE FOR，在this博客文章中描述。

來源

2009-01-17 00:04:38

有趣的是，我們這裏並沒有真正的DBA。不知何故，數據庫在沒有任何干預的情況下繼續進行卡車運輸，並且已有多年。但是我有權在服務器上做很多事情，所以也許我會開始嘲笑這個東西。感謝指針。 – recursive 2009-01-17 00:18:57

Managment Studio和TableAdapter之間存儲過程的執行時間差異很大

回答

相關問題