SQL Server 在處理存儲過程的時候，為了節省編譯時間，是一次編譯，多次重用。當第一次運行時代入值產生的執行計劃，不適用后續代入的參數時，就產生了parameter sniffing問題。 create procedure Sniff1(@i int) as SELECT count(b.SalesOrderID),sum(p.weight) from [Sale
SQL Server 在處理存儲過程的時候，為了節省編譯時間，是一次編譯，多次重用。當第一次運行時代入值產生的執行計劃，不適用后續代入的參數時，就產生了parameter sniffing問題。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
create procedure Sniff1(@i int) asSELECT count(b.SalesOrderID),sum(p.weight) from[Sales].[SalesOrderHeader] ainner join [Sales].[SalesOrderDetail] bon a.SalesOrderID = b.SalesOrderIDinner join Production.Product pon b.ProductID = p.ProductIDwhere a.SalesOrderID =@i;goDBCC FREEPROCCACHEexec Sniff1 50000;exec Sniff1 75124;go |
Parameter Sniffing問題發生不頻繁，只會發生在數據分布不均勻或者代入參數值不均勻的情況下?，F在，我們就來探討下如何解決這類問題。
1. 使用Exec() 方式運行動態SQL
|
1
2
3
4
5
6
7
8
9
10
11
|
create procedure Nosniff1(@i int) asdeclare @cmd varchar(1000);set @cmd = 'SELECT count(b.SalesOrderID),sum(p.weight) from [Sales].[SalesOrderHeader] ainner join [Sales].[SalesOrderDetail] bon a.SalesOrderID = b.SalesOrderIDinner join Production.Product pon b.ProductID = p.ProductIDwhere a.SalesOrderID ='; exec(@cmd+@i); go |
exec Nosniff1 50000;
exec Nosniff1 75124;
從上述trace中可以看到，在執行查詢語句之前，都有SP: CacheInsert事件，SQL Server做了動態編譯，根據變量的值，都正確的預估了結果集，給出了不同的執行計劃。
2. 使用本地變量
|
1
2
3
4
5
6
7
8
9
10
11
|
create procedure Nosniff2(@i int) asdeclare @iin int;set @iin=@iSELECT count(b.SalesOrderID),sum(p.weight) from[Sales].[SalesOrderHeader] ainner join [Sales].[SalesOrderDetail] bon a.SalesOrderID = b.SalesOrderIDinner join Production.Product pon b.ProductID = p.ProductIDwhere a.SalesOrderID =@iin;go |
exec Nosniff2 50000;
exec Nosniff2 75124;
如上一篇文章所述，使用本地變量，參數值在存儲過程語句執行過程中得到，SQL Server在運行時不知道變量的值，會根據一個預估值進行編譯，給出一個折中的執行計劃。
3. 使用Query Hint，指定執行計劃
在 SELECT、DELETE、UPDATE 和 MERGE 語句最后加上OPTION ( [ ,...n ] )，對執行計劃進行指導。當數據庫管理員知道問題所在時，可以通過hint引導SQL Server生成一個對所有變量都不太差的執行計劃。
以上所述是小編給大家介紹的SQL Server Parameter Sniffing及其改進方法，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回復大家的。在此也非常感謝大家對服務器之家網站的支持！
