最近遇到一個問題，兩個頁面查詢非常慢，需要30~40秒，而相同的程式碼通過Microsoft SQL Server Management Studio或者VS的SQL查詢工具查詢卻能秒出資料，感到非常奇怪。

如果修改儲存過程，短時段內恢復正常，過一段時間又重新出現問題，大概是儲存過程計劃快取的問題，可以試下重新編譯儲存過程：

exec sp_recompile @objname='儲存過程名稱'

ASP.NET呼叫SQL後臺儲存過程時，有時突然就變得很慢，在後臺直接執行儲存過程沒問題，但在前臺呼叫儲存過程時就是很慢，而且在前臺呼叫成功後，再次呼叫還是一樣的慢，但更新一下儲存過程再呼叫就很快了。但這始終不能徹底解決問題，過段時間又會出來同樣的問題。

如果判定是快取的問題解決辦法可以參考下面的方法:

方法一：在可能比較耗時的語句後面加上option(recompile)

方法二：強制編譯儲存過程

SQL Server 提供三種重新編譯儲存過程的方法：

(1)、sp_recompile 系統儲存過程強制在下次執行儲存過程時進行重新編譯。

　　示例：exec sp_recompile 儲存過程名

(2)、建立儲存過程時在其定義中指定 WITH RECOMPILE 選項，表明 SQL Server 將不對該儲存過程計劃進行快取記憶體；該儲存過程將在每次執行時都重新編譯。

　　示例：Create Proc 儲存過程名 WITH RECOMPILE AS 引數

(3)、在執行儲存過程時指定 WITH RECOMPILE 選項，可強制對儲存過程進行重新編譯。僅當所提供的引數不典型，或者自建立該儲存過程後資料發生顯著更改時才應使用此選項。

　　示例：儲存過程名 WITH RECOMPILE

如果無法判定是快取引起的可以試試下面的這樣辦法:

把執行Procedure 的引數直接拼好傳遞給查詢語句執行代替從程式碼中直接呼叫儲存過程。

建立 CommandType = CommandType.Text 的 DbCommand 物件,再呼叫

ExecuteDataSet("EXEC PRO_SFDAB008_QUERY '',null,'2009-01-01','2014-01-01' ");
 

把執行Procedure 的引數直接拼好傳遞。