源博客地址 https://blog.csdn.net/pgbiao/article/details/22388945html
其餘參考：參數探測(Parameter Sniffing)影響存儲過程執行效率解決方案post
這篇文章對參數嗅探問題做了很詳細的研究 https://www.cnblogs.com/lyhabc/articles/3222179.html測試
這兩天遇到一個問題使人比較鬱悶，一個大概120行左右的存儲過程在SQL Server2012的查詢分析器裏面執行，
速度很是理想，1秒不到，便可篩選抓取到大概500條數據記錄。
但在C#程序代碼裏調用，就提示鏈接超時。把CommandTimeout設置爲300，就要3分鐘左右時間才能顯示出來，
檢查了幾遍代碼也沒有發現錯誤。問題依舊。
緣由分析：
一、因爲在查詢分析器裏執行速度很快，而且數據量也很少。
二、只在程序裏調用纔有緩慢的狀況。
三、設置CommandTimeout參數，就能夠顯示結果出來，但要好久。
綜上分析，初步判定問題出在C#代碼上。但檢查後沒有收穫。
在百度上查詢這方面的資料。
在CSDN論壇上終於找到相似的資料貼子。其中有一網友在回覆中說「有多是執行計劃過時吧」，
真是一言驚醒夢中的我。
當即在查詢分析器上執行：url
exec sp_recompile @objname='存儲過程名稱'spa
再次測試程序，此次終於成功了。速度很滿意。
緣由分析：
因爲存儲過程是預編譯的, 在第一次執行的時候, 會生成執行計劃, 之後執行的時候, 會使用這個執行計劃(除非存儲過程侯或者顯示指定從新編譯), 而不是每次執行時都去生成執行計劃。
當存儲過程涉及的對象結構調整, 或者相關的數據產生了很大變化, 這可能致使原來的計劃不適合當前的現狀(執行計劃過時), 這種狀況下應該從新編譯存儲過程。.net
若是修改一次不行，能夠再修改一次，再等會測試htm