Parameter sniffing (1/2)

This problem will be solved in parameter words SQL sentence （ For example, stored procedures ） And SQL Server When the plan caching mechanism in is combined . This article is divided into 2 Parts of , The first 1 Part will introduce Parameters of sniffer （Parameter Sniffing） Overview of , The first 2 In part, let's introduce how to solve this problem .

What is parameter sniffing （Parameter Sniffing）

stay SQL Server When you execute parameters SQL When inquiring , The query optimizer will compile the execution plan based on the first provided parameter value . Then the generated execution plan is cached in the plan cache for later reuse . That is to say SQL Server This plan will be reused directly in the future , Regardless of the different parameter values you provide each time . We need to identify 2 Class parameter values ：

• Parameter compilation value （Compile time values）
• Parameter operation value （Runtime values）

The parameter compilation value is the value used to query the optimizer to generate the physical execution plan . The parameter operation value is the value provided to execute the planned operation . These values are consistent for the first execution , But the next execution , These values are likely to be different . This will cause serious performance problems , Because the execution plan is optimized only for compiling values , It is not optimized for the different running values you provide next .

If you provide a specific value during the first query execution , Then the query optimizer selects nonclustered index lookup and bookmark lookup operators to get all query columns from your table . Such an execution plan only makes sense for a specific value , If it is not a specific value , Your logic reading will be very high ,SQL Server Will select full table scan , Ignore defined nonclustered indexes .SQL Server Choose this 2 The decision point of a plan is the so-called critical point （Tipping Point） .

If the bookmark lookup plan is cached ,SQL Server You won't care about the input value , Blindly reuse cached plans . In this case SQL Server The protection mechanism of is invalid , Only execute cached plans from the plan cache . As a side effect , Yours IO cost （ Logical capital ） It'll burst your watch , The performance of queries will be very poor . Let's demonstrate this situation , The following script will create a simple table , At the bottom of the table 2 There is an uneven data distribution （ Just the second 1 The entry value is 1, The rest 1499 All values are 2）.

 1 -- Create a test table
 2 CREATE TABLE Table1
 3 (
 4     Column1 INT IDENTITY,
 5     Column2 INT
 6 )
 7 GO
 8 
 9 CREATE NONCLUSTERED INDEX idx_Test ON Table1(Column2)
10 
11 -- Insert 1500 records into Table1
12 INSERT INTO Table1 (Column2) VALUES (1)
13 
14 SELECT TOP 1499 IDENTITY(INT, 1, 1) AS n INTO #Nums
15 FROM
16 master.dbo.syscolumns sc1
17 
18 INSERT INTO Table1 (Column2)
19 SELECT 2 FROM #nums
20 DROP TABLE #nums
21 GO

Based on this uneven data distribution and critical point , For the same logical query, there will be 2 Different execution plans , Click on the toolbar The display contains the actual execution plan ：

1 SELECT * FROM dbo.Table1 WHERE Column2=1
2 SELECT * FROM dbo.Table1 WHERE Column2=2

Now when you create a stored procedure , The query optimizer will generate an execution plan based on the parameter values provided for the first time , Then it will be blindly reused in the next execution .

1 -- Create a new stored procedure for data retrieval
2 CREATE PROCEDURE RetrieveData
3 (
4     @Col2Value INT
5 )
6 AS
7     SELECT * FROM Table1
8     WHERE Column2 = @Col2Value
9 GO

 

1 SET STATISTICS IO ON 
2 EXEC dbo.RetrieveData @Col2Value = 1 -- int
3 EXEC dbo.RetrieveData @Col2Value = 2 -- int

Now when you use 1 Value when running stored procedures , Only return 1 Bar record , The query optimizer selects bookmarks in the execution plan to find . Queries only produce 3 A logical reading . But when you use 2 Value when running stored procedures , Cached plans are reused , Bookmark search is performed repeatedly 1499 Time . Execute on each record ！ The query is now generated 1505 A logical reading . This is completely different from the implementation just now . When you look 2 In the implementation plan ,SELECT Operator properties , In the parameter list, you can see ：

As you can see, they are different , The parameter compilation value is 1, The parameter operation value is 2. That is to say, the execution in front of you is based on the parameter value 1 And optimized , But in fact, the parameter value you pass to the stored procedure is 2. This is it. SQL Server Inside Parameters of sniffer （Parameter Sniffing） problem .

Summary

  As you can see , stay SQL Server It's easy to encounter this problem in . Every time you use parameters SQL Inquire about （ Like in a stored procedure ）, When the table data is unevenly distributed , When the provided nonclustered index does not overwrite the query column , You will encounter this problem . Here we only introduce this problem , I will show you in the next article How to deal with this problem , namely SQL Server What solutions have been provided to you to solve this problem .

—— Reproduced in : http://www.cnblogs.com/woodytu/p/4551004.html