今天一個生成10w條數據的存儲過程執行了95s,但是單獨執行SQL語句只需要28s,查資料后發現原來這是存儲過程的機制導致的，也就是傳說中的參數嗅探
網上的一段話：
（1）可能是發生了參數嗅探，第一次賦給存儲過程的輸入參數，會為該存儲過程生成一個基於輸入參數的執行計划，因此如果第一次輸入的參數不具有代表性（例如大部分查詢輸入的參數都是A值，但第一次執行存儲過程時輸入的是B值），就有可能比即席查詢慢，盡管即席查詢需要重新編譯執行計划，但選擇了更有效率的計划。
嘗試使用和即席查詢一樣的參數，來執行存儲過程，然后對比一下兩者的執行計划。
（2）通常存儲過程最上面有自帶的set設置，如set ansi_nulls on，而即席查詢通常沒有包含，這些set設置也會影響執行計划。
嘗試在即席查詢中添加上，與存儲過程一樣的set設置，然后再對比一下執行計划。
把存儲過程的參數賦值給了存儲過程中自定義的變量，整個存儲過程中使用這個變量來代替參數，執行速度就和執行SQL一樣了
一篇介紹參數嗅探的好文：http://www.cnblogs.com/lyhabc/archive/2013/03/02/2941144.html