媽媽說我,從小記性就很差,什麼東西都要記下來才行。html
現象描述: 環境是 .NET 4.0,數據庫是SQL2008,存儲過程在數據庫中執行很快,可是使用代碼調用時異常的緩慢。數據庫操做類代碼是使用 Microsoft.Practices.EnterpriseLibrary.Data.Database.GetStoredProcCommand
建立 StoredProcedure
類型 Commond
對象,而後使用 ExecuteDataSet
方法執行的。數據庫
1). 發生某一個存儲過程執行異常緩慢,而其它的'小夥伴'都很正常。c#
(排除數據庫瞬間壓力的可能)有時候發生這種沒法解釋的問題,大都是人品問題。通常處理方法就是Drop 掉存儲過程或者 Recomplie (語法: exec sp_recompile @objname='存儲過程的名字')一下。若是這個還不行,恭喜你能夠玩一下' 刪空格' 遊戲了。有時候咱們會發現查詢語句中多了意外的全角空格會致使查詢錯誤或者執行異常,因此無論什麼空格,把多餘的全刪除下,從新執行也許就順利經過了。固然這個不必定適用你的狀況,沒辦法的時候只能死馬全當活馬醫了。緩存
2)若是廣泛或者較多的存儲過程都出現這種讓人糾結的問題。框架
應該考慮是否是哪裏疏忽了,由於咱們在作測試的時候可能傳入了和程序中不同的限制條件致使的。一開始我也不相信本身會犯這樣的錯誤,可是當我去檢查代碼的時候發現,原來本身推測的傳入參數太‘天真’了(說實話咱們項目組剛發生了這樣的狀況,搞的一星期都是在開會研究確認這個問題,而後向總部提交了疑難問題,結果在第二週的時候發現原來咱們都天真了一把。)。因此仍是要檢查一下代碼確認本身已經很純潔了,再來考慮是否是代碼框架發生了問題。測試
ASP.NET調用SQL後臺存儲過程時,有時忽然就變得很慢,在後臺直接執行存儲過程沒問題,但在前臺調用存儲過程時就是很慢,並且在前臺調用成功後,再次調用仍是同樣的慢,但更新一下存儲過程再調用就很快了。但這始終不能完全解決問題,過段時間又會出來一樣的問題。優化
若是斷定是緩存的問題解決辦法能夠參考下面的方法:.net
方法一:在可能比較耗時的語句後面加上option(recompile)code
方法二:強制編譯存儲過程htm
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 對象,再調用
<!-- lang: c# --> ExecuteDataSet("EXEC PRO_SFDAB008_QUERY '',null,'2009-01-01','2014-01-01' ");
把執行Procedure 的參數直接拼好傳遞。
上面的方法不必定管用,可是在沒有辦法的時候試一試老是能夠的。
百度參考: SQL優化之存儲過程強制編譯