何謂SQLSERVER引數嗅探問題
大家聽到“嗅探”這個詞應該會覺得跟黑客肯定有關係吧,使用工具嗅探一下引數,然後截獲,脫褲o(∩_∩)o 。
事實上,我覺得大家太敏感了,其實這篇文章跟資料庫安全沒有什麼關係,實際上跟資料庫效能調優有關
相信大家有泡SQLSERVER論壇的話不多不少應該都會見過“引數嗅探”這幾個字
這裡有三篇帖子都是講述引數嗅探的
http://social.msdn.microsoft.com/Forums/zh-CN/sqlserverzhchs/thread/caccb7f3-8366-4954-8f8a-145eb6bca9dd
http://msdn.microsoft.com/zh-cn/magazine/ee236412.aspx
http://social.msdn.microsoft.com/Forums/zh-CN/sqlserverzhchs/thread/bfbe54de-ac00-49e9-a83b-f97a60bf74ef
下面我給出一個測試資料庫的備份檔案,裡面有一些表和一些測試資料 ,大家可以去下載,因為我下面用的測試表都是這個資料庫裡的
只需要還原資料庫就可以了,這個資料庫是SQL2005版本的,資料庫名:AdventureWorks
下面只需要用到三張表,表裡面有索引:
[Production].[Product] [SalesOrderHeader_test] [SalesOrderDetail_test]
資料庫下載連結:AdventureWorks
其實簡單來講,引數嗅探我的很通俗的解釋就是:SQLSERVER用鼻子嗅不到具體引數是多少
所以他不能選擇最合適的執行計劃去執行你的查詢,所以引數嗅探是一個不好的現象。
想真正瞭解引數嗅探,大家可以先建立下面兩個儲存過程
儲存過程一:
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
儲存過程二:
複製程式碼 程式碼如下: 1 USE [AdventureWorks] 2 GO 3 DROP PROC Sniff2 4 GO 5 CREATE PROC Sniff2(@i INT) 6 AS 7 DECLARE @j INT 8 SET @j=@i 9 SELECT COUNT(b.[SalesOrderID]),SUM(p.[Weight])10 FROM [dbo].[SalesOrderHeader_test] a11 INNER JOIN [dbo].[SalesOrderDetail_test] b12 ON a.[SalesOrderID]=b.[SalesOrderID]13 INNER JOIN [Production].[Product] p14 ON b.[ProductID]=p.[ProductID]15 WHERE a.[SalesOrderID]=@j16 GO
然後請做下面這兩個測試
測試一:
--測試一: 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 SET STATISTICS PROFILE ON EXEC [dbo].[Sniff] @i = 75124 -- int --發生編譯,插入一個使用hash match聯接的執行計劃 GO EXEC [dbo].[Sniff] @i = 50000 -- int --發生執行計劃重用,重用上面的hash match的執行計劃 GO
從上面兩個測試可以清楚地看到執行計劃重用的副作用。
由於資料分佈差別很大引數50000和75124只對自己生成的執行計劃有好的效能,
如果使用對方生成的執行計劃,效能就會下降。引數50000返回的結果集比較小,
所以效能下降不太嚴重。引數75124返回的結果集大,就有了明顯的效能下降,兩個執行計劃的差別有近10倍
對於這種因為重用他人生成的執行計劃而導致的水土不服現象,SQSERVERL有一個專有名詞,叫“引數嗅探 parameter sniffing”
因為語句的執行計劃對變數的值很敏感,而導致重用執行計劃會遇到效能問題,就是我上面說的
“
SQLSERVER用鼻子嗅不到具體引數是多少,所以他不能選擇最合適的執行計劃去執行你的查詢
”
本地變數的影響
那對於有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的時候,做得非常準確,選擇了最適合他們的執行計劃
但是對於第三句和第四句,SQLSERVER不知道@j的值是多少,所以在做EstimateRows的時候,不管代入的@i值是多少,
一律給@j一樣的預測結果。所以兩個執行計劃是完全一樣的(都是Hash Match)。
引數嗅探的解決辦法
引數嗅探的問題發生的頻率並不高,他只會發生在一些表格裡的資料分佈很不均勻,或者使用者帶入的引數值很不均勻的情況下。
由於篇幅原因我就不具體說了,只是做一些歸納
(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
(2)使用本地變數local variable
(3)在語句裡使用query hint,指定執行計劃
在select,insert,update,delete語句的最後,可以加一個"option(<query_hint>)"的子句
對SQLSERVER將要生成的執行計劃進行指導。當DBA知道問題所在以後,可以通過加hint的方式,引導
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
(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
對於Plan Guide,他還可以使用在一般的語句調優裡
終於搞定了,因為要搞測試資料的原因所以搞了很久啊~~
總結
以上所述是小編給大家介紹的何謂SQLSERVER引數嗅探問題,希望對大家有所幫助!