Parameter sniffing (2/2)

stay Parameters of sniffer （Parameter Sniffing）（1/2) in , I introduced SQL Server The basic concept and problems behind parameter sniffing . As you can see , When the cached plan is SQL Server When reusing blindly , Can cause serious performance problems . Today I will show you how to deal with this problem , That is to use different technologies to overcome it .

Indexes （Index）

Last time we discussed that the root cause of the parameter sniffing problem is ： In the execution plan ,SQL Statement sometimes produces bookmark lookup , Sometimes a table is generated / Clustered index scan . If you can modify the index in the database , The simplest way to solve this problem is to provide the corresponding Overwrite nonclustered indexes . Here we will include the required columns for bookmark search , In the leaf layer of nonclustered indexes . After doing this , You can get Plan stability ： Regardless of any parameters of the input provided , The query optimizer can compile the same execution plan —— It is used here Index lookup （ Nonclustered indexes ） Operator .

1 DROP  INDEX idx_Test ON Table1
2 CREATE NONCLUSTERED INDEX idx_Test ON Table1(Column2) INCLUDE(Column1)
3 
4 SELECT * FROM dbo.Table1 WHERE Column2=1
5 SELECT * FROM dbo.Table1 WHERE Column2=2

If you can't modify your index design , Try the following ：

Recompile （Recompilation）

SQL Server The first option provided to you is to perform the recompilation of the plan . It provides 2 There are different options for you to use ：

• Recompile all , The whole stored procedure
• There is a problem SQL Statement recompile , That is to say Statement level recompilation （ from SQL Server 2005 Available from ）

Let's explain this in detail through examples 2 An option . The following statement will recompile the entire stored procedure ：

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

When you execute such a stored procedure , The query optimizer recompiles the stored procedure before each execution . Therefore, the execution plans you get are based on the currently entered parameter values . As a side effect of recompilation , Your execution plan will not be cached , Caching an execution plan that is recompiled every time is meaningless . When you have a large complex stored procedure used at the stored procedure level RECOMPILE Options , It doesn't make much sense to do so , Because of you. Whole Store recompile every time , And the stored procedure is for compilation and reuse , So as to improve the execution efficiency .

1 EXEC dbo.RetrieveDataR @Col2Value = 1 -- int
2 EXEC dbo.RetrieveDataR @Col2Value = 2 -- int

If your parameter sniffing problem only occurs in a specific SQL sentence . Then there is no need to recompile the whole stored procedure . So from SQL Server2005 Start , The offer is called Statement level recompilation （Statement Level Recompilation） . You can recompile those that need to be recompiled SQL Sentence plus RECOMPILE Query prompts instead of the entire stored procedure . Let's take a look at the following code ：

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

The first in the above example 2 individual SQL Statements will be recompiled when the stored procedure is executed . The first 1 Statements are compiled at the beginning of execution , And generate a plan cache for subsequent reuse . When you don't want to modify the index of the database , This method is the recommended method for handling parameter sniffing .

1 EXEC dbo.RetrieveDataR2 @Col2Value = 2 -- int

 OPTIMIZE FOR

Except stored procedures or SQL Recompile query prompt of statement ,SQL Server Also provide OPTIMIZE FOR Query prompt . With this query prompt, you can tell the query optimizer which parameter value , Optimize the execution plan , Let's look at the following example ：

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

From the definition of stored procedure, you can see ,SQL The execution plan of the statement is in the parameter @Col2Value The value is 1 It needs to be optimized . No matter what value you provide to this parameter , You get value 1 Optimized compilation plan . In this way, you have been right SQL Server Zoom in , Because the query optimizer has no other options —— It must be a parameter value 1 Generate optimized execution plan . When you know that the query plan needs to be optimized for the specified parameters , You can use this method to make SQL Server Optimize the execution plan of this parameter . After you restart SQL Server Or perform cluster failover , You can predict your implementation plan .

To further ensure the effectiveness of this option , You need to be familiar with your data distribution , When will the data distribution change . If the data distribution has changed , You have to modify the query prompt , See if it's still appropriate . You can't completely trust the query optimizer , Because you have used OPTIMIZE FOR Query prompt resets the selection of the query optimizer . Remember this . In addition, we are providing OPTIMIZE FOR While querying the prompt ,SQL Server Also provide OPTIMIZE FOR UNKNOWN Query hints . If you decide to use OPTIMIZE FOR UNKNOWN Query hints , The query optimizer uses the density in the table statistics to make parameter estimation . If the logical reading exceeds critical point , Still use tables / An index scan …… 

Summary

In this article, I show you in SQL Server Different ways to deal with parameter sniffing in . The most common cause of this problem is poor index design , After the parameter value is passed in, the optimizer selects bookmark search in the execution plan . If such an execution plan is reused by the cache , Yours I/O The cost will explode . In the build environment , I saw that for this reason 100GB The logic of reading . stay SQL Add a simple RECOMPILE Query tips can solve this problem , Queries only add a small amount of logical reads .

If you can't modify the database index design , You can use stored procedures or SQL Use... In sentences RECOMPILE Query hints . Plans compiled as a side effect will not be cached . In addition to other query tips ,SQL Server Also provide OPTIMIZE FOR and OPTIMIZE FOR UNKNOWN Query prompt . When you use these query prompts , You should be very familiar with your data and data distribution , Because you are resetting the optimizer . Please use ！Be always aware of this fact!

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