筆記51-徐 參數嗅探 Parameter Sniffing 

--參數嗅探 Parameter Sniffing  2013-2-8

--當使用存儲過程的時候，總是要使用到一些變量。變量有兩種，一種
--是在存儲過程的外面定義的。當調用存儲過程的時候，必須要給他代入
--值。這種變量，SQL在編譯的時候知道他的值是多少。

--例如：
USE [AdventureWorks]
GO
DROP PROC Sniff
GO
CREATE PROC Sniff(@i INT)
AS
SELECT COUNT(b.[SalesOrderID]),SUM(p.[Weight])
FROM [dbo].[SalesOrderHeader_test] a
INNER JOIN [dbo].[SalesOrderDetail_test] b
ON a.[SalesOrderID]=b.[SalesOrderID]
INNER JOIN [Production].[Product] p
ON b.[ProductID]=p.[ProductID]
WHERE a.[SalesOrderID]=@i
GO

--這里的變量@i，就是要在調用的時候代入值的
EXEC [dbo].[Sniff] @i = 50000 -- int
GO


--還有一種變量是在存儲過程里面定義的。他的值在存儲過程的語句執行的過程中得到的。
--所以對這種本地變量，SQL在編譯的時候不知道他的值是多少。
--例如：
USE [AdventureWorks]
GO
DROP PROC Sniff2
GO
CREATE PROC Sniff2(@i INT)
AS
DECLARE @j INT
SET @j=@i
SELECT COUNT(b.[SalesOrderID]),SUM(p.[Weight])
FROM [dbo].[SalesOrderHeader_test] a
INNER JOIN [dbo].[SalesOrderDetail_test] b
ON a.[SalesOrderID]=b.[SalesOrderID]
INNER JOIN [Production].[Product] p
ON b.[ProductID]=p.[ProductID]
WHERE a.[SalesOrderID]=@j
GO

EXEC [dbo].[Sniff2] @i = 500000 -- int
GO



--這里的變量@j，是SQL在運行的過程中算出來的
--已經談到過多次，SQL在處理存儲過程的時候，為了節省編譯時間，
--是一次編譯，多次重用的。用sp_executesql的方式調用的指令也是
--這樣。那么執行計划重用就有兩個潛在問題


--（1）對於第一類變量，根據第一次運行時代入的值生成的執行計划，是不是
--就能夠適合所有可能的變量值呢？


--（2）對於第二類本地變量，SQL在編譯的時候並不知道他的值是多少，那怎么
--選擇“合適”的執行計划呢？

--對於第一個問題，會引出對 “參數嗅探”問題的定義。而對於第二個問題，本節
--將介紹使用本地變量對執行計划選擇的影響。最后介紹參數嗅探問題的候選
--解決方案


------------------------------------------------------------------------
--什么是參數嗅探
--帶着第一個問題，請做下面這兩個測試
--測試一：
USE [AdventureWorks]
GO
DBCC freeproccache
GO
EXEC [dbo].[Sniff] @i = 500000 -- int
--發生編譯，插入一個使用nested loops聯接的執行計划
GO

EXEC [dbo].[Sniff] @i = 75124 -- int
--發生執行計划重用，重用上面的nested loops的執行計划
GO

--測試二：

USE [AdventureWorks]
GO
DBCC freeproccache
GO
EXEC [dbo].[Sniff] @i = 75124 -- int
--發生編譯，插入一個使用hash match聯接的執行計划
GO

EXEC [dbo].[Sniff] @i = 50000 -- int
--發生執行計划重用，重用上面的hash match的執行計划
GO


--從上面兩個測試可以清楚地看到執行計划重用的副作用。由於數據分布差別很大
--參數50000和75124只對自己生成的執行計划有好的性能，如果使用對方生成的
--執行計划，性能就會下降。參數50000返回的結果集比較小，所以性能下降
--不太嚴重。參數75124返回的結果集大，就有了明顯的性能下降，兩個執行計划
--的差別有近10倍

--對於這種因為重用他人生成的執行計划而導致的水土不服現象，SQL有一個專有
--名詞，叫“參數嗅探 parameter sniffing”是因為語句的執行計划對變量的值
--很敏感，而導致重用執行計划會遇到性能問題


--本地變量的影響
--那對於有parameter sniffing問題的存儲過程，如果使用本地變量，會怎樣呢？
--下面請看測試3。這次用不同的變量值時，都清空執行計划緩存，迫使其
--重編譯
--第一次
USE [AdventureWorks]
GO
DBCC freeproccache
GO
SET STATISTICS TIME ON
SET STATISTICS PROFILE ON
EXEC [dbo].[Sniff] @i = 50000 -- int
GO
------------------------------
--第二次
USE [AdventureWorks]
GO
DBCC freeproccache
GO
SET STATISTICS TIME ON
SET STATISTICS PROFILE ON
EXEC [dbo].[Sniff] @i = 75124 -- int
GO
--------------------------------
--第三次
USE [AdventureWorks]
GO
DBCC freeproccache
GO
SET STATISTICS TIME ON
SET STATISTICS PROFILE ON
EXEC [dbo].[Sniff2] @i = 50000 -- int
GO
---------------------------------
--第四次
USE [AdventureWorks]
GO
DBCC freeproccache
GO
SET STATISTICS TIME ON
SET STATISTICS PROFILE ON
EXEC [dbo].[Sniff2] @i = 75124 -- int
GO


--來看他們的執行計划：
--對於第一句和第二句，因為SQL在編譯的時候知道變量的值，所以在做EstimateRows的時候，
--做得非常准確，選擇了最適合他們的執行計划


--但是對於第三句和第四句，SQL不知道@j的值是多少，所以在做EstimateRows的時候，
--不管代入的@i值是多少，一律給@j一樣的預測結果。所以兩個執行計划是完全一樣的。
--這里EstimateRows的大小，在語句1和語句2的值之間，所以他選擇的執行計划，和
--語句1與語句2都不一樣

--我們再來比較一下不同執行計划下的速度
--------------------------------------
--第一次
SQL Server 執行時間:
   CPU 時間 = 0 毫秒，占用時間 = 715 毫秒。

SQL Server 執行時間:
   CPU 時間 = 16 毫秒，占用時間 = 1775 毫秒。
--------------------------------------------
--------------------------------------
--第二次
SQL Server 執行時間:
   CPU 時間 = 998 毫秒，占用時間 = 9821 毫秒。

SQL Server 執行時間:
   CPU 時間 = 998 毫秒，占用時間 = 9906 毫秒。
--------------------------------------------
--------------------------------------
--第三次
SQL Server 執行時間:
   CPU 時間 = 15 毫秒，占用時間 = 57 毫秒。

SQL Server 執行時間:
   CPU 時間 = 15 毫秒，占用時間 = 66 毫秒。
--------------------------------------------
--------------------------------------
--第四次
SQL Server 執行時間:
   CPU 時間 = 1981 毫秒，占用時間 = 6926 毫秒。

SQL Server 執行時間:
   CPU 時間 = 1997 毫秒，占用時間 = 6933 毫秒。
--------------------------------------------

--有參數嗅探的情況，語句三和語句四作出來的執行計划是一種比較中庸的方法，不是最快的
--也不是最慢的。他對語句性能的影響，一般不會有參數嗅探那么嚴重，他還是解決
--參數嗅探的一個候選方案


---------------------------------------------------------------------------------
--參數嗅探的解決方案

--參數嗅探的問題發生的頻率並不高，他只會發生在一些表格里的數據分布很不均勻，或者
--用戶帶入的參數值很不均勻的情況下。例如，查詢一個時間段數據的存儲過程，如果
--大部分用戶都只查1天的數據，SQL緩存的也是這樣的執行計划，那對於那些要查一年
--的數據，可是SQL碰到“參數嗅探”問題的風險了。如果系統里大部分用戶都要查一年的數據
--可是SQL碰巧緩存了一個只查一天數據的存儲過程，那大部分用戶都會遇到“參數嗅探”的問題
--這個對性能的影響就大了

--有什么辦法能夠緩解，或者避免參數嗅探問題呢？在SQL2005以后，可以有很多種方法可供
--選擇

--（1）用exec()的方式運行動態SQL
--如果在存儲過程里不是直接運行語句，而是把語句帶上變量，生成一個字符串，再讓exec()這樣
--的命令做動態語句運行，那SQL就會在運行到這句話的時候，對動態語句進行編譯。這時SQL
--已經知道了變量的值，會根據生成優化的執行計划，從而繞過參數嗅探問題

--例如前面的存儲過程Sniff，就可以改成這樣
USE [AdventureWorks]
GO
DROP PROC NOSniff
GO
CREATE PROC NOSniff(@i INT)
AS
DECLARE @cmd VARCHAR(1000)
SET @cmd='SELECT COUNT(b.[SalesOrderID]),SUM(p.[Weight])
FROM [dbo].[SalesOrderHeader_test] a
INNER JOIN [dbo].[SalesOrderDetail_test] b
ON a.[SalesOrderID]=b.[SalesOrderID]
INNER JOIN [Production].[Product] p
ON b.[ProductID]=p.[ProductID]
WHERE a.[SalesOrderID]='
EXEC(@cmd+@i)
GO

--然后再用上面的順序調用會得到比他更好的性能

USE [AdventureWorks]
GO
DBCC freeproccache
GO
SET STATISTICS TIME ON
SET STATISTICS PROFILE ON
EXEC [dbo].NOSniff @i = 50000 -- int
GO
--------------------------------
USE [AdventureWorks]
GO
SET STATISTICS TIME ON
SET STATISTICS PROFILE ON
EXEC [dbo].NOSniff @i = 75124 -- int
GO



--使用exec()的方式產生動態編譯
--在查詢語句執行之前，都能看見SP:CacheInsert事件。SQL做了動態編譯，根據變量的值，
--正確地估計出每一步的返回結果集大小。所以這兩個執行計划，是完全不一樣的

--執行結果很快，這種方法的好處，是徹底避免參數嗅探問題。但缺點是要修改存儲過程
--的定義，而且放棄了存儲過程一次編譯，多次運行的優點，在編譯性能上有所損失


--（2）使用本地變量local variable
--在前面，提到了如果把變量值賦給一個本地變量，SQL在編譯的時候是沒辦法知道這個本地
--變量的值的。所以他會根據表格里數據的一般分布情況，“猜測”一個返回值。不管用戶
--在調用存儲過程的時候代入的變量值是多少，做出來的執行計划都是一樣的。而這樣
--的執行計划一般比較“中庸”，不會是最優的執行計划，但是對大多數變量值來講，也不會
--是一個很差的執行計划

--存儲過程[Sniff2]就是這樣一個例子
--這種方法的好處，是保持了存儲過程的優點，缺點是要修改存儲過程，而且執行計划也不是
--最優的



--（3）在語句里使用query hint，指定執行計划
--在select,insert,update,delete語句的最后，可以加一個"option(<query_hint>)"的子句
--對SQL將要生成的執行計划進行指導。當DBA知道問題所在以后，可以通過加hint的方式，引導
--SQL生成一個比較安全的，對所有可能的變量值都不差的執行計划

--現在SQL的query hint還是很強大的，有十幾種hint。完整的定義是：
--msdn：http://msdn.microsoft.com/zh-cn/library/foo66fb1520-dcdf-4aab-9ff1-7de8f79e5b2d.aspx
<query_hint > ::=
{ { HASH | ORDER } GROUP
  | { CONCAT | HASH | MERGE } UNION
  | { LOOP | MERGE | HASH } JOIN
  | FAST number_rows
  | FORCE ORDER
  | MAXDOP number_of_processors
  | OPTIMIZE FOR ( @variable_name = literal_constant [ , ...n ] )
  | PARAMETERIZATION { SIMPLE | FORCED }
  | RECOMPILE
  | ROBUST PLAN
  | KEEP PLAN
  | KEEPFIXED PLAN
  | EXPAND VIEWS
  | MAXRECURSION number
  | USE PLAN N'xml_plan'
}


--這些hint的用途不一樣。有些是引導執行計划使用什么樣的運算的，比如，
--  | { CONCAT | HASH | MERGE } UNION
--  | { LOOP | MERGE | HASH } JOIN

--有些是防止重編譯的，例如
--  | PARAMETERIZATION { SIMPLE | FORCED }
--  | KEEP PLAN
--  | KEEPFIXED PLAN


--有些是強制重編譯的，例如
--  | RECOMPILE


--有些是影響執行計划的選擇的，例如
--| FAST number_rows
--| FORCE ORDER
--| MAXDOP number_of_processors
--| OPTIMIZE FOR ( @variable_name = literal_constant [ , ...n ] )

--所以他們適合在不同的場合。具體的定義，請看SQL的聯機幫助

--為了避免參數嗅探的問題，有下面幾種常見的query hint使用方法

--（1）recompile
--recompile這個查詢提示告訴SQL，語句在每一次存儲過程運行的時候，都要重新編譯一下。
--這樣能夠使SQL根據當前變量的值，選一個最好的執行計划。對前面的那個例子，我們可以
--這樣寫
USE [AdventureWorks]
GO
DROP PROC NoSniff_QueryHint_Recompile
GO
CREATE PROC NoSniff_QueryHint_Recompile(@i INT)
AS
SELECT COUNT(b.[SalesOrderID]),SUM(p.[Weight])
FROM [dbo].[SalesOrderHeader_test] a
INNER JOIN [dbo].[SalesOrderDetail_test] b
ON a.[SalesOrderID]=b.[SalesOrderID]
INNER JOIN [Production].[Product] p
ON b.[ProductID]=p.[ProductID]
WHERE a.[SalesOrderID]=@i
OPTION(RECOMPILE)
GO

--------------------------------------
USE [AdventureWorks]
GO
DBCC freeproccache
GO
EXEC NoSniff_QueryHint_Recompile 50000
GO
-------------------------------------
USE [AdventureWorks]
GO
EXEC NoSniff_QueryHint_Recompile 75124
GO


--在SQL Trace里我們能夠看到,語句運行之前,都會有一個SQL:StmtRecompile的事件發生
--而使用的執行計划，就是最准確的那種
--和這種方法類似，是在存儲過程的定義里直接指定“recompile”，也能達到避免
--參數嗅探的效果

USE [AdventureWorks]
GO
DROP PROC NoSniff_SPCreate_Recompile
GO
CREATE PROC NoSniff_SPCreate_Recompile(@i INT)
WITH RECOMPILE
AS
SELECT COUNT(b.[SalesOrderID]),SUM(p.[Weight])
FROM [dbo].[SalesOrderHeader_test] a
INNER JOIN [dbo].[SalesOrderDetail_test] b
ON a.[SalesOrderID]=b.[SalesOrderID]
INNER JOIN [Production].[Product] p
ON b.[ProductID]=p.[ProductID]
WHERE a.[SalesOrderID]=@i
GO


-------------------------------------------------
USE [AdventureWorks]
GO
DBCC freeproccache
GO
EXEC NoSniff_SPCreate_Recompile 50000
GO

------------------------------------------------
USE [AdventureWorks]
GO
EXEC NoSniff_QueryHint_Recompile 75124
GO


--在SQL Trace里,我們能看到,存儲過程在執行的時候已經找不到前面的執行計划
--SP:CacheMiss,所以要生成新的。而使用的執行計划，就是最准確的那種

--這兩種“Recompile”提示的差別是，如果在語句層次指定OPTION(RECOMPILE)，
--那存儲過程級別的計划重用還是會有的。只是在運行到那句話的時候，才會發生重編譯。
--如果存儲過程里有if-else之類的邏輯，使得發生問題的語句沒有執行到，那重編譯就不會發生。
--所以，這是一種問題精確定位后，比較精細的一種調優方法。如果在存儲過程級別
--指定WITH RECOMPILE，那整個存儲過程在每次執行的時候都要重編譯，這個重復工作量就比較大了
--但是，如果問題沒有精確定位，可以用這種方法快速緩解問題



--（2）指定join運算 { LOOP | MERGE | HASH } JOIN
--很多時候，參數嗅探問題是由於SQL對一個該用merge join/hash join的情況誤用了
--nested loops join。確定了問題后，當然可以用查詢提示，指定語句里所有join方法。
--但是這種方法一般很不推薦，因為不是所有的join，SQL都能夠根據你給的提示做出來
--執行計划的。如果對例子存儲過程的那個查詢最后加上“option(hash join)”，運行
--的時候會返回這樣的錯誤。SQL不接受這個查詢提示：

消息 8622，級別 16，狀態 1，第 1 行
由於此查詢中定義了提示，查詢處理器未能生成查詢計划。請重新提交查詢，
並且不要在查詢中指定任何提示，也不要使用 SET FORCEPLAN。


--更常見的是，在特定的那個join上使用join hint。這種方法成功幾率要高得多
--例如：
USE [AdventureWorks]
GO
DROP PROC NoSniff_QueryHint_JoinHint
GO
CREATE PROC NoSniff_QueryHint_JoinHint(@i INT)
AS
SELECT COUNT(b.[SalesOrderID]),SUM(p.[Weight])
FROM [dbo].[SalesOrderHeader_test] a
INNER JOIN [dbo].[SalesOrderDetail_test] b
ON a.[SalesOrderID]=b.[SalesOrderID]
INNER hash JOIN [Production].[Product] p
ON b.[ProductID]=p.[ProductID]
WHERE a.[SalesOrderID]=@i
GO


USE [AdventureWorks]
GO
DBCC freeproccache
GO
SET STATISTICS PROFILE ON
GO
EXEC NoSniff_QueryHint_JoinHint 50000
GO
---------------------------------------------
USE [AdventureWorks]
GO
SET STATISTICS PROFILE ON
GO
EXEC NoSniff_QueryHint_JoinHint 75124
GO



--這種方法的好處，是保持了存儲過程一次編譯，后續多次使用的特性，節省編譯時間。
--但是缺點也很明顯，使用這樣的方法生成執行計划，不一定就是一個好的執行計划
--而且表格里的數據量變化以后，現在合適的join方式將來可能就不合適，到時候還會
--造成性能問題，所以使用的時候要很小心




--（3）OPTIMIZE FOR ( @variable_name = literal_constant [ , ...n ] )
--當確認了參數嗅探問題后，發現，根據某些變量值生成的執行計划，快和慢會相差
--很大，而根據另外一些變量生成的執行計划，性能在好和壞的時候，相差並不很大。
--例如當變量等於50000的時候，他用最好的nested loops執行計划，用時十幾毫秒，
--用hash join的那個執行計划，也不過300多毫秒。但是變量等於75124的時候，
--hash join執行計划需要500多毫秒，用nested loops的時候，要用4000多。
--從絕對值來講，讓用戶等幾百毫秒一般是沒問題的。但是等上幾秒鍾，就容易
--收到抱怨了。所以hash join是一個比較“安全”的執行計划。如果SQL總是使用75124
--這個值做執行計划，會對大部分查詢都比較安全。

--使用OPTIMIZE FOR這個查詢指導，就能夠讓SQL做到這一點。這是SQL2005以后的一個新
--功能。

USE [AdventureWorks]
GO
DROP PROC NoSniff_QueryHint_OptimizeFor
GO
CREATE PROC NoSniff_QueryHint_OptimizeFor(@i INT)
AS
SELECT COUNT(b.[SalesOrderID]),SUM(p.[Weight])
FROM [dbo].[SalesOrderHeader_test] a
INNER JOIN [dbo].[SalesOrderDetail_test] b
ON a.[SalesOrderID]=b.[SalesOrderID]
INNER hash JOIN [Production].[Product] p
ON b.[ProductID]=p.[ProductID]
WHERE a.[SalesOrderID]=@i
OPTION(optimize FOR(@i=75124))
GO
---------------------------------
USE [AdventureWorks]
GO
DBCC freeproccache
GO
SET STATISTICS PROFILE ON
GO
EXEC NoSniff_QueryHint_OptimizeFor 50000
GO
---------------------------------------------
USE [AdventureWorks]
GO
SET STATISTICS PROFILE ON
GO
EXEC NoSniff_QueryHint_OptimizeFor 75124
GO


--從SQL Trace里看，存儲過程第一次運行時有編譯，但是第二次就出現了執行計划重用
--分析執行計划會發現SQL在第一次編譯時，雖然變量值是50000，他還是根據75124
--來做預估的，EstimateRows的值很大。正因為這樣，第二次運行也有不錯的性能

--這種方法的優點是，既能夠讓SQL作出有傾向性的執行計划，又能保證SQL選擇執行計划
--時候的自由度，所以得到的執行計划一般是比較好的。相對於用join hint，這個方法
--更精細一些。缺點是，如果表格里的數據分布發生了變化，比如用戶有一天把
--75124的記錄全刪除了，那SQL選擇的執行計划就不一定繼續正確了。所以他也有他
--的局限性。


--上面介紹的方法，都有一個明顯的局限性，那就要去修改存儲過程定義。有些時候沒有
--應用開發組的許可，修改存儲過程是不可以的。對用sp_executesql的方式調用的指令，
--問題更大。因為這些指令可能是寫在應用程序里，而不是SQL里。DBA是沒辦法去修改
--應用程序的。

--好在SQL2005和2008里，引入和完善了一個種叫Plan Guide的功能。DBA可以告訴SQL，當
--運行某一個語句的時候，請你使用我指定的執行計划。這樣就不需要去修改存儲過程或
--應用了。



--（4）Plan Guide
--例如可以用下面的方法，在原來那個有參數嗅探問題的存儲過程“Sniff”上，解決sniffing問題
USE [AdventureWorks]
GO
EXEC [sys].[sp_create_plan_guide]
@name=N'Guide1',
@stmt=N'SELECT COUNT(b.[SalesOrderID]),SUM(p.[Weight])
FROM [dbo].[SalesOrderHeader_test] a
INNER JOIN [dbo].[SalesOrderDetail_test] b
ON a.[SalesOrderID]=b.[SalesOrderID]
INNER JOIN [Production].[Product] p
ON b.[ProductID]=p.[ProductID]
WHERE a.[SalesOrderID]=@i',
@type=N'OBJECT',
@module_or_batch=N'Sniff',
@params=NULL,
@hints=N'option(optimize for(@i=75124))';
GO

-----------------------------------
USE [AdventureWorks]
GO
SET STATISTICS PROFILE ON
GO
DBCC freeproccache
GO
EXEC [dbo].[Sniff] @i = 50000 -- int
GO

--使用了75124的hash match的join方式

--對於Plan Guide，他還可以使用在一般的語句調優里。在后面的章節會介紹


-----------------------各種方法的比較-----------------------------------
--      方法                 是否修改存儲過程             是否每次運行都要重編譯          執行計划准確度
--用exec()方式運行動態SQL          需要                        會                             很准確
--使用本地變量local variable       需要                        不會                            一般
--query hint+"recompile"           需要                        會                              很准確
--query  hint指定join運算          需要                        不會                            很一般
--query hint optimize for          需要                        不會                            比較准確
--Plan Guide                       不需要                      不會                            比較准確


--DBA可以根據實際情況，選擇對他最合適的解決方案