今天乙個生成10w條資料的儲存過程執行了95s,但是單獨執行sql語句只需要28s,查資料後發現原來這是儲存過程的機制導致的，也就是傳說中的引數嗅探
網上的一段話：
（1）可能是發生了引數嗅探，第一次賦給儲存過程的輸入引數，會為該儲存過程生成乙個基於輸入引數的執行計畫，因此如果第一次輸入的引數不具有代表性（例如大部分查詢輸入的引數都是a值，但第一次執行儲存過程時輸入的是b值），就有可能比即席查詢慢，儘管即席查詢需要重新編譯執行計畫，但選擇了更有效率的計畫。
嘗試使用和即席查詢一樣的引數，來執行儲存過程，然後對比一下兩者的執行計畫。
（2）通常儲存過程最上面有自帶的set設定，如set ansi_nulls on，而即席查詢通常沒有包含，這些set設定也會影響執行計畫。
嘗試在即席查詢中新增上，與儲存過程一樣的set設定，然後再對比一下執行計畫。
把儲存過程的引數賦值給了儲存過程中自定義的變數，整個儲存過程中使用這個變數來代替引數，執行速度就和執行sql一樣了
一篇介紹引數嗅探的好文：
mysql慢查詢，處理sql語句執行速度慢問題
臨時開啟慢日誌 如重啟資料庫，還會改為預設值off，如需永久改需要修改配置檔案 show variables like slow query log 如果查詢出的值為off則需要開啟慢日誌 set global slow query log on 開啟慢日誌 設定1秒以上為慢查詢 如重啟資料庫，還會...
SQL Server 查詢執行過的sql語句與效能
select top1000 st.textas 執行的sql語句 qs.execution count as 執行次數 qs.total elapsed time as 耗時 qs.total logical reads as 邏輯讀取次數 qs.total logical writes as 邏...
用臨時表改善巢狀SQL語句的執行速度
檢查一條巢狀 sql語句，發覺非常耗時。形如 select keyid,count 1 as num from table1 where 1 1 andcreatedate 2007 09 21 andkeyid in select keyid from table2 where id 1611 g...