什么参数嗅探

当SQL Server第一次执行查询语句或存储过程（或者查询语句与存储过程被强制重新编译）的时候，SQL Server会有一个进程来评估传入的参数，并根据传入的参数生成对应的执行计划缓存，然后参数的值会伴随查询语句或存储过程执行计划一并保存在执行计划缓存里。这个评估的过程就叫做参数嗅探。

SQL Server对查询语句编译和缓存机制是SQL语句执行过程中非常重要的环节，也是SQLOS内存管理非常重要的一环。理由是SQL Server对查询语句编译过程是非常消耗系统性能，代价昂贵的。因为它需要从成百上千条执行路径中选择一条最优的执行计划方案。所以，查询语句可以重用执行计划的缓存，避免重复编译，以此来节约系统开销。这种编译查询语句，选择最优执行方案，缓存执行计划的机制就是参数嗅探问题产生的理论基础。

参数嗅探的表象

以上是比较枯燥的理论解释，这里我们来看看两个实际的例子。在此，我们以AdventureWorks2008R2数据库中的Sales.SalesOrderDetail表做为我们测试的数据源，我们挑选其中三个典型的产品，ProductID分别为897，945和870，分别对应的订单总数为2，257和4688。 挑选的方法如下：

得到如下结果：

接下来，我们看三个非常相似的查询语句（仅传入的参数值不同）的执行计划有什么差异。 三个查询语句：

  2. GO
  3. SELECT SalesOrderDetailID, OrderQty
  4. FROM Sales.SalesOrderDetail WITH(NOLOCK)
  5. WHERE ProductID = 897;
  7. SELECT SalesOrderDetailID, OrderQty
  8. FROM Sales.SalesOrderDetail WITH(NOLOCK)
  9. WHERE ProductID = 945;
  11. SELECT SalesOrderDetailID, OrderQty
  12. FROM Sales.SalesOrderDetail WITH(NOLOCK)
  13. WHERE ProductID = 870;

分别的执行计划： 02__ 从这个执行计划对比来看，ProductID为945和897的两条语句执行计划一致，因为满足条件的记录数非常少，分别为257条和2条，所以SQL Server均选择走最优执行计划Index Seek + Key Lookup。但是与ProductID为870的查询语句执行计划完全不同，这条语句SQL Server选择走的是Clustered Index Scan，几乎等价于Table Scan的性能消耗。这是因为，SQL Server认为满足条件ProductID = 870的记录数太多，达到了4688条记录，与其走Index Seek + Key Lookup，还不如走Clustered Index Scan顺序IO的效率高。从这里可以看出，SQL Server会因为传入参数值的不同而选择走不同的执行计划，执行效率也大不相同。确切的说，这个就是属于查询语句的参数嗅探问题范畴。

存储过程的参数嗅探表象

上一小节，我们看了查询语句的参数嗅探表象，这一小节我们来看看存储过程参数嗅探的表象又是如何的呢？ 首先，我们创建如下存储过程:

  1. USE AdventureWorks2008R2
  2. GO
  3. CREATE PROCEDURE UP_GetOrderIDAndOrderQtyByProductID(
  4. @ProductID INT
  5. )
  6. AS
  7. BEGIN
  8.     SET NOCOUNT ON
  9.     SELECT 
  10.         SalesOrderDetailID
  11.         , OrderQty
  12.     FROM Sales.SalesOrderDetail WITH(NOLOCK)
  13.     WHERE ProductID = @ProductID;
  14. END
  15. GO

接下来，我们执行两次这个存储过程，传入不同的参数：

  1. EXEC dbo.UP_GetOrderIDAndOrderQtyByProductID 870
  2. EXEC dbo.UP_GetOrderIDAndOrderQtyByProductID 945

从这个执行计划来看，ProductID为870和945走的相同的执行计划Clustered Index Scan，这个和上一小节得到的结果是不一样的。上一节中ProductID = 945的查询语句执行计划走的是Index Seek + Key Lookup。

这到底是为什么呢？从另外一个角度来讲，这个不正确的统计估值甚至会导致SQL Server走到一个不是最优的执行计划上来（根据上一小节，ProductID = 945的最优执行计划其实是Index Seek + Key Lookup）。 答案其实就是存储过程的参数嗅探问题。这是因为，我们在首次执行这个存储过程的时候，传入的参数ProductID = 870对应的订单总数为4668，SQL Server在编译，缓存执行计划的时候，连同这个值一起记录到执行计划缓存中了。从而影响到存储过程的第二次及以后的执行计划方案，进而影响到存储过程的执行效率。 我们可以通过如下方法来查看执行计划中传入参数的值，右键 => Show Execution Plan XML => 搜索 ParameterCompiledValue 05__ 在此例中，我们很清楚的发现传入参数值是870，同时也很清楚得看到了参数嗅探对于执行计划的影响：

  1. ...
  2. <ColumnReference Column="@ProductID" ParameterCompiledValue="(870)" ParameterRuntimeValue="(870)" />
  3. ...

至此，我们分别从查询语句和存储过程两个方便看到了参数嗅探的表象。

从参数嗅探的表象这一章节，我们可以对此参数嗅探的问题窥探一二。但是，参数嗅探可能会导致哪些常见的问题呢？根据我们的经验，如果你遭遇了MSSQL Server以下奇怪问题，你可能就遇到参数嗅探这个“大魔头”了。

某些传入参数导致存储过程执行非常缓慢，但是ALTER PROCDURE（所有代码没做任何改动）后，性能恢复正常。这个场景是我们之前经常遇到的，原因是当你ALTER PROCEDURE后，MSSQL Server会主动清除对应的存储过程执行计划缓存，然后再次执行该存储过程的时候，系统会重新编译并缓存该存储过程执行计划。

相同的存储过程，相同的传入参数，执行时快时慢

这个听起来非常奇怪吧，当我们执行相同的存储过程，传入相同的参数值，但是执行效率时快时慢，请注意下面例子中的注释部分。

现在我们清空了执行计划缓存，为了方便，我直接清除所有的执行计划缓存。

  1. DBCC FREEPROCCACHE

再次执行存储过程，这次我们交换了执行顺序，先执行ProductID 945，然后执行ProductID 870。

  1. USE AdventureWorks2008R2
  2. GO
  3. --SQL Server 创建执行计划，优化ProductID = 945，对应于小量订单的最优执行计划，运行时间100毫秒
  4. EXEC dbo.UP_GetOrderIDAndOrderQtyByProductID 945
  6. --SQL Server直接获取缓存中的执行计划，对于大量订单的ProductID 870来说，可能是很差的执行计划，执行时间60秒

从这两个批次执行的时间对比来看，ProductID 945和870执行时间有比较大的差异，特别是ProductID = 870。这种相同的存储过程，相同的传入参数，执行时快时慢的问题，也是由于参数嗅探导致的。 注意：这里只是为了描述这种现象，由于表数据量本来不大的原因，可能实际上执行时间可能没有那么大的差异。

某一个查询语句，放在存储过程中执行和拿出来单独执行，时间消耗差异大，一般情况是拿出来单独执行的语句很快，放到存储过程中执行很慢。这个情况也是我们在产品环境常见的一种典型参数嗅探导致的问题。

参数嗅探的解决方法

上一节，我们探讨了参数嗅探可能会导致的问题。当发现这些问题的时候，我们来看看两类人的不同解决方法。请允许我将这两类人分别命名为菜鸟和老鸟，没有任何歧视，只是一个名字代号而已。

菜鸟的解决方法

  • 方法一：重启Windows OS。果然很黄很暴力，重启Windows操作系统，彻底清空Windows所有内存内容。
  • 方法二：重启SQL Server Service。稍微温柔一点点啦，重启SQL Server Service，彻底清空SQL Server占用的所有内存，当然执行计划缓存也被清空了。
  • 方法三：DBCC命令清空SQL Server执行计划缓存。又温柔了不少吧，彻底清空了SQL Server所有的执行计划缓存，包含有问题的和没有问题的缓存。
  1. DBCC FREEPROCCACHE

当菜鸟还在为自己的解决方法解决了参数嗅探问题而沾沾自喜的时候，老鸟的思维已经走得很远很远了，老鸟就是老鸟，是菜鸟所望尘莫及的。老鸟的思维逻辑其实也很简单，既然是某个或者某些查询语句或存储过程的执行计划缓存有问题，那么，我们只需要重新编译缓存这些害群之马就好了。

  • 方法一：创建存储过程使用WITH RECOMPILE
  1. USE AdventureWorks2008R2
  2. GO
  3. ALTER PROCEDURE dbo.UP_GetOrderIDAndOrderQtyByProductID(
  4. @ProductID INT
  6. WITH RECOMPILE
  7. AS
  8. BEGIN
  9.     SET NOCOUNT ON
  10.     SELECT 
  11.         SalesOrderDetailID
  12.         , OrderQty
  13.     FROM Sales.SalesOrderDetail WITH(NOLOCK)
  14.     WHERE ProductID = @ProductID;
  15. END
  16. GO

再重新执行两次存储过程，传入不同的参数值，我们可以看到均走到最优的执行计划上来了，说明参数嗅探的问题已经解决。这个方法带来的一个问题就是每次执行这个存储过程系统都会重新编译，无法使用执行计划缓存。但是相对来说，重新编译的系统开销要远远小于参数嗅探导致的系统性能消耗，所以，两害取其轻。

  • 方法二：查询语句使用Query Hits

如果我们知道ProductID对应的订单总数分布，认为ProductID = 945为最好的执行计划，那么我们可以强制SQL Server按照参数输入945来执行存储过程，我们可以添加Query Hits来实现。这种方法的难点在于对表中数据分布有着精细的认识，可操作性不强，因为表中数据分布是随时在改变的。

  • 方法三：DBCC清除特定语句或存储过程缓存

当清除执行计划缓存后，SQL Server再次执行会重新编译对应语句或者存储过程，以获得最好的执行计划。在此以清除特定存储过程执行计划缓存为例。

  1. USE AdventureWorks2008R2
  2. GO
  4. declare
  5.       @plan_id varbinary(64)
  6. ;
  8. SELECT TOP 1 @plan_id = cache.plan_handle
  9. FROM sys.dm_exec_cached_plans cache 
  10. CROSS APPLY sys.dm_exec_query_plan(cache.plan_handle) AS pla
  11. CROSS APPLY sys.dm_exec_sql_text(cache.plan_handle) AS txt
  12. WHERE pla.objectid  = object_id(N'UP_GetOrderIDAndOrderQtyByProductID','P')
  13. and  txt.objectid  = object_id(N'UP_GetOrderIDAndOrderQtyByProductID','P')
  15. DBCC FREEPROCCACHE (@plan_id); 
  16. GO
  • 方法四：更新表对象统计信息

表统计信息过时导致执行计划评估不准确，进而影响查询语句执行效率。这个也是导致参数嗅探问题另一个重要原因。这种情况，我们只需要手动更新表统计信息。这个解决方法的难点在于找到有问题的查询语句和对应有问题的表。统计信息更新方法如下，如果发现StatsUpdated时间太过久远就应该是被怀疑的对象：

  1. USE AdventureWorks2008R2
  2. GO
  3. UPDATE STATISTICS Sales.SalesOrderDetail WITH FULLSCAN;
  5. SELECT 
  6.     name AS index_name
  7.     , STATS_DATE(OBJECT_ID, index_id) AS StatsUpdated
  8. FROM sys.indexes
  9. WHERE OBJECT_ID = OBJECT_ID('Sales.SalesOrderDetail')
  10. GO
  • 方法五：重整表对象索引

另外一个导致执行计划评估不准确的重要原因是索引碎片过高（超过30%），这个也会导致参数嗅探问题的重要原因。这种情况我们需要手动重整索引碎片，方法如下：

  1. USE AdventureWorks2008R2
  2. GO
  3.         DB_NAME = DB_NAME(database_id)
  4.         ,SCHEMA_NAME = SCHEMA_NAME(schema_id)
  5.         ,OBJECT_NAME = tb.name
  6.         ,ix.name
  7.         ,avg_fragmentation_in_percent
  9.     CROSS APPLY sys.indexes AS ix WITH (NOLOCK)
  10.     INNER JOIN sys.tables as tb WITH(NOLOCK)
  11.     ON ix.object_id = tb.object_id
  12. WHERE ix.object_id = fra.object_id
  13.     and ix.index_id = fra.index_id
  15. USE AdventureWorks2008R2
  16. GO
  17. ALTER INDEX PK_SalesOrderDetail_SalesOrderID_SalesOrderDetailID
  18. ON Sales.SalesOrderDetail REBUILD;
  • 方法六：创建缺失的索引

还有一个重要的导致执行计划评估不准确的因素是表缺失索引，这个也是会导致参数嗅探的问题。查找缺失索引的方法如下：

  1. USE AdventureWorks2008R2
  2. GO
  3. SELECT TOP 10
  4.     database_name = db_name(details.database_id)
  5.     , schema_name = SCHEMA_NAME(tb.schema_id)
  6.     , object_name = tb.name
  7.     , avg_estimated_impact = dm_migs.avg_user_impact*(dm_migs.user_seeks+dm_migs.user_scans)
  8.     , last_user_seek = dm_migs.last_user_seek
  9.     , create_index = 
  10. 'CREATE INDEX [IX_' + OBJECT_NAME(details.OBJECT_ID,details.database_id) + '_'
  11. + REPLACE(REPLACE(REPLACE(ISNULL(details.equality_columns,''),', ','_'),'[',''),']','') 
  12. + CASE
  13.     WHEN details.equality_columns IS NOT NULL
  14.     AND details.inequality_columns IS NOT NULL THEN '_'
  15.     ELSE ''
  16.     END
  17.     + REPLACE(REPLACE(REPLACE(ISNULL(details.inequality_columns,''),', ','_'),'[',''),']','')
  18.     + ']'
  19.     + ' ON ' + details.statement
  20.     + ' (' + ISNULL (details.equality_columns,'')
  21.     + CASE WHEN details.equality_columns IS NOT NULL AND details.inequality_columns 
  22.     IS NOT NULL THEN ',' ELSE
  23.     '' END
  24.     + ISNULL (details.inequality_columns, '')
  25.     + ')'
  26.     + ISNULL (' INCLUDE (' + details.included_columns + ')', '')
  27. FROM sys.dm_db_missing_index_groups AS dm_mig WITH(NOLOCK)
  28.     INNER JOIN sys.dm_db_missing_index_group_stats AS dm_migs WITH(NOLOCK)
  29.     ON dm_migs.group_handle = dm_mig.index_group_handle
  30.     INNER JOIN sys.dm_db_missing_index_details AS details WITH(NOLOCK)
  31.     ON dm_mig.index_handle = details.index_handle
  32.     INNER JOIN sys.tables AS tb WITH(NOLOCK)
  33.     ON details.object_id = tb.object_id
  34. WHERE details.database_ID = DB_ID()
  35. ORDER BY Avg_Estimated_Impact DESC

这是一个非常奇怪的解决方法，使用这种方法的原因是，对于本地变量SQL Server使用统计密度来代替统计直方图，它会认为所有的本地变量均拥有相同的统计密度，即对应于相同的记录数。这样可以避免因为数据分布不均匀导致的参数嗅探问题。

至此结束，本节分享了菜鸟和老鸟关于参数嗅探问题的解决方法，我相信大家应该可以轻松的做出正确选择适合自己的解决方法。

以上所有代码的测试环境是在MSSQL Server 2008R2 Enterprise中完成。

  1. Microsoft SQL Server 2008 R2 (SP2) - 10.50.4000.0 (X64)   Jun 28 2012 08:36:30   Copyright (c) Microsoft Corporation  Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)