昨天一開發同事反饋一個存儲過程很慢，但是重編譯後，存儲過程就很快了。了解基本情況後，初步判斷是參數嗅探問題。那麽如何診斷定位、分析問題呢？下面簡單介紹一下這次參數嗅探問題定位的流程過程。

首先查看該存儲過程的執行計劃相關信息：

如下截圖所示，此存儲過程是2018-09-12 9:03：01緩存的，最後一次執行是2018-09-14 08:58，而且自上次緩存後，執行了24875次。從這裏我們基本判斷該存儲過程一直在重用緩存的執行計劃，而且沒有產生重編譯現象。

SELECT  d.object_id ,

        d.database_id ,

        OBJECT_NAME(object_id, database_id) ‘proc name‘
 
 ,

        d.cached_time ,

        d.last_execution_time ,

        d.total_elapsed_time ,

        d.total_elapsed_time / d.execution_count AS [avg_elapsed_time] ,

        d.last_elapsed_time ,

        d.execution_count

FROM    sys.dm_exec_procedure_stats AS d

WHERE   OBJECT_NAME(object_id, database_id) = ‘sp_GetOTList‘
 

ORDER BY [total_worker_time] DESC;  

然後我們使用下面腳本找到該存儲過程的實際執行計劃，將存儲過程的執行計劃的XML內容拷貝到Plan Explorer工具。生成比較清晰、詳細的執行計劃圖。

SELECT

        d.object_id ,

        DB_NAME(d.database_id) DBName ,

        OBJECT_NAME(object_id, database_id) ‘SPName‘ ,

        d.cached_time ,

        d.last_execution_time ,

        d.total_elapsed_time/1000000    AS total_elapsed_time,

        d.total_elapsed_time / d.execution_count/1000000 

                                        AS [avg_elapsed_time] ,

        d.last_elapsed_time/1000000        AS last_elapsed_time,

        d.execution_count ,

        d.total_physical_reads ,

        d.last_physical_reads ,

        d.total_logical_writes ,

        d.last_logical_reads ,

        et.text SQLText ,

        eqp.query_plan executionplan

FROM    sys.dm_exec_procedure_stats AS d

CROSS APPLY sys.dm_exec_sql_text(d.sql_handle) et

CROSS APPLY sys.dm_exec_query_plan(d.plan_handle) eqp

WHERE   OBJECT_NAME(object_id, database_id) = ‘sp_GetOTList‘

ORDER BY [total_worker_time] DESC;

如下截圖所示，我們可以清晰的找到Est Cost、 Est Cpu Cost、 Est IO Cost等高的SQL語句（其實這個是實際執行計劃，而不是預估的執行計劃），

然後重點研究、對比， 然後使用WITH(RECOMPILE)重新執行該存儲過程，生成新的執行計劃，然後按照上面方式將存儲過程執行計劃的XML拷貝到Plan Explorer工具裏面。 然後我們可以對比、研究看看到底出現了什麽情況

舊的實際執行計劃

如上截圖所示，開銷最大的SQL語句的實際執行計劃如上所示，註意開銷占比最大的地方。 下面截圖是Nested Loops裏面循環的次數（叠代次數20次），也是我們

對比執行計劃需要重點關註的地方

新的實際執行計劃

新的執行計劃中，可以看到舊執行計劃開銷最大的SQL語句在整體開銷的占比減少了很多，但是該語句的新舊執行計劃是一樣的。唯一不同的就是兩個Nested Loops裏面循環的次數不一樣。這個就是產生性能差異的地方，如果對嵌套循環連接不太熟悉，可以參考一下下面這段內容:

Nested Loops也稱為嵌套叠代，它將一個聯接輸入用作外部輸入表（顯示為圖形執行計劃中的頂端輸入），將另一個聯接輸入用作內部（底端）輸入表。外部循環逐行消耗外部輸入表。內部循環為每個外部行執行，在內部輸入表中搜索匹配行。最簡單的情況是，搜索時掃描整個表或索引；這稱為單純嵌套循環聯接。如果搜索時使用索引，則稱為索引嵌套循環聯接。如果將索引生成為查詢計劃的一部分（並在查詢完成後立即將索引破壞），則稱為臨時索引嵌套循環聯接。

舊執行計劃：

嵌套循環次數：20* 30

嵌套循環次數：20*20

新執行計劃：

嵌套循環次數： 1* 1

嵌套循環次數： 1* 1

那麽為什麽產生這個差異，就是因為存儲過程裏面一段SQL語句使用了存儲過程參數，而恰巧裏面那個表按照這個字段的數據分布很不均衡。所以當存儲過程按照第一次傳入的參數生成執行計劃並緩存下來，而按照那個參數生成的執行計劃並不是一直都是最優執行計劃，那麽就導致了性能問題出現了，這也就是參數嗅探問題。

解決方法

在SQL語句後面使用HINT提示來解決參數嗅探，本想在對應的SQL語句後面使用OPTION (RECOMPILE) ,但是考慮此存儲過程調用頻繁，而且同事極力推薦使用提示OPTION (OPTIMIZE FOR UNKNOWN).修改過後，性能測試效果也確實顯著。

一次存儲過程參數嗅探定位流程總結