在之前的随笔中，我提到了参数嗅探，这是非常重要的概念。接下来我们将深入探讨参数嗅探。
首先，我们知道批处理可以是参数化的或非参数化的。参数化的批处理计划有两种类型：“Prepared”或“Proc”。前者对应于至少包含一个参数的sys.sp_executesql的执行，并且可以从T-SQL批处理或通过ADO.NET等应用程序直接执行。后者对应于存储过程的执行计划。
参数嗅探在两种类型中的行为是完全相同的。因此，我们在这里不讨论类型，而只关注参数化批处理本身的作用。
什么是参数嗅探？
当批处理包含一个或多个参数并且需要优化时（例如，因为没有该批处理的执行计划缓存或只有不可用的计划），优化器会知道参数的值。这意味着优化器可以使用参数值来估计计划中每个步骤返回的行数，就好像参数的值被硬编码到批处理的文本中一样。这就是参数嗅探。
参数嗅探非常有用，因为如果优化器不知道参数的值，它将不得不猜测返回的行数。基于平均统计和其他元数据尽可能准确地猜测，但大多数情况下仍然与实际行数相去甚远。错误的估计会导致选择低效的执行计划，从而导致性能很差。
例如，一个批处理第一次被执行时，因为对应计划在计划缓存中不存在，所以首先需要编译。在编译时，由于参数嗅探，参数的值将被用来生成执行计划。生成的计划会被放入缓存中以供重用。下次执行相同的批处理时，尽管可能使用了不同的参数，但缓存中的计划仍将被重用。当然，第二次执行的结果将基于参数的值。但执行第二次的计划与第一次是相同的，这个计划就是基于第一次执行的参数生成的。
如图所示。在参数化批处理的实际执行计划的图形表示中，查看最外层的操作符属性（通常是一个select操作符），然后找到“Parameter List”属性。展开属性时，将会看到每个参数在编译时和运行时的值。编译时的值就是参数嗅探用来生成计划的参数。运行时的值是实际在指定计划中的参数。
采用目前业界最流行的模版编译系统，所有的页面都可以实现在线/离线修改，只需简单掌握HTML的知识，就可以轻松创建属于自己的个性化的专业用户界面，内建多语言包替换模块，独创的商品参数模版系统，强大的后台管理支持和数据备份功能
实际上，第二次执行的性能可能很差，因为优化器在两次生成计划时估计返回数据的行数可能相差很大。这完全是运气，没有更好的方法。执行计划由参数的值决定，而我们无法控制它，因为不知道编译何时发生。如果计划对于大多数执行都很高效，那么一切正常；但如果不是呢？如果用户使用一个很少使用的参数来执行存储过程，这个参数值生成的执行计划对于指定该值作为参数的执行可能非常高效，但对于其他参数则会表现得很糟糕。
因此问题来了：参数嗅探是好还是不好？
一如往常，答案是：“看情况”。这取决于数据的分布。让我们看一下之前使用的存储过程：
CREATE PROCEDURE Marketing.usp_CustomersByCountry(
@Country AS NCHAR(2))
AS
SELECT
Id,
Name,
LastPurchaseDate
FROM
Marketing.Customers
WHERE
Country = @Country;
GO在这种情况下，使用参数@Country来过滤customers表的行数。如果大多数国家有相似的行数，并且大多数执行使用这些国家，那么参数嗅探就是好事，因为大多数情况下的执行计划是适用的，并且比没有参数嗅探的计划（未知参数）要好。另一方面，如果国家的值分布不均匀，那么一个国家编码的参数对于其他国家的查询计划可能是一个糟糕的选择，此时参数嗅探就是坏事。
那么我们在参数嗅探是否有益这件事情上能做什么？下一章将介绍如何高效地使用参数嗅探。
发布者：全栈程序员栈长，转载请注明出处：https://www.php.cn/link/efb926bfce4f58539b1c2b45a5676b09 原文链接：https://www.php.cn/link/c8377ad2a50fb65de28b11cfc628d75c
