问题标签 [parameter-sniffing]

我sp_executesql用来传递带有几个参数的复杂选择。这样做比将其从存储过程中取出并声明变量要慢得多。

我已经看到很多关于 SQL 参数嗅探的问题，我的场景听起来可能就是这种情况。然而，即使在使用它调用DBCC FREEPROCCACHE或修改外部 Select 之后，与Option (Recompile)在存储过程之外编写相同的查询相比，它仍然使用不同且低效的执行计划。

然而，仍然使用存储过程但将参数的副本设置为局部变量将使用有效的执行计划。

这种情况是否排除了 SQL 参数嗅探的原因？因为我重新编译查询肯定没有它使用的预先存在的执行计划。如果是这样，这种行为的其他可能原因是什么？

只是为了让您了解 sql 查询，您可以在下面看到它（通过实体框架生成的混乱）。这是快速查询，但是当放入sp_executesqlproc 并取出变量并放入参数时，它会生成低效的执行计划

我在 SQL Server 2012 中遇到了经典的参数嗅探问题。根据一些研究，我发现了围绕这个问题的多种选择。我需要了解两者之间区别的两个选项是OPTION(OPTIMIZE FOR UNKNOWN)vs OPTION(RECOMPILE)。

我犹豫是否OPTION(RECOMPILE)在遇到此问题的查询结束时使用它，因为它会强制服务器每次生成一个新的执行计划。如果我经常调用这个查询，这会增加那台机器的 CPU。

所以我使用他最好的解决方案，这两个选项之间的真正区别是什么？

会OPTION(OPTIMIZE FOR UNKNOWN)重用缓存而不是每次都重新编译吗？

我有一个 SELECT 语句（不是存储过程），用于在 SSRS（Visual Studio 2010）中创建报告。

参数@ClassCode 是引起麻烦的参数。但是在开发中它工作正常，但是当我将它部署到生产时它会永远呈现。

我假设它是一个参数嗅探，并且我阅读了如何在存储过程中修复它。但我没有 SP，我使用的是 SELECT 语句。

SELECT 语句的解决方法是什么？环境之间有什么区别？生产要强大得多。我的查询如下：

以下查询将在大约 22 秒内运行：

问题在于变量赋值（实际上是这一行：）@x = AncestorId。删除分配时，它的速度高达约 15 毫秒！我通过将结果插入临时表来解决它，但我认为这是一个不好的方法。

谁能帮我解决问题的根源是什么？！

附言

糟糕的执行计划（22秒）：https ://www.brentozar.com/pastetheplan/?id=Sy6a4c9bW

良好的执行计划（20毫秒）：https ://www.brentozar.com/pastetheplan/?id=Byg8Hc5ZZ

我已经开始创建一个存储过程，它将根据传递的参数搜索我的数据库表。到目前为止，我已经听说过kitchen sink parameter sniffing. 有几篇文章有助于理解这个问题，但我仍然不是 100% 有一个好的解决方案。我在系统中有几个屏幕将在我的数据库中搜索不同的表。它们都具有用户将选择和搜索的三个不同标准。第一个标准是Status可以是Active，Inactive或All。接下来是Filter By，这可以根据表和列数为用户提供不同的选项。通常，用户可以选择按Name、Code、Number、DOB、Email、UserName或Show All. 每个搜索屏幕至少有 3 个过滤器，其中一个是Show All. 我创建了一个存储过程，用户可以在其中搜索Status和Filter By Name，Code或Show All。我遇到的一个问题是Status过滤器。似乎 SQL 将检查 where 子句中的所有选项，所以如果我通过参数1SP 返回所有活动记录，如果我通过0则只有非活动记录。问题是如果我通过2SP 应该返回所有记录（活动和非活动），但我只看到活动记录。这是一个例子：

除了状态过滤器的问题，我想知道参数嗅探是否还有其他问题？我发现了一篇关于防止嗅探的博客，其中一种方法是声明局部变量。如果有人对状态过滤器有建议或解决方案，请告诉我。

我有一个简单的查询，按日期范围返回订单列表。此查询用于向其提供参数（站点、起始日期和截止日期）的报告中。

这个查询的问题是它花费的时间太长并且问题行是

变量站点的格式类似于“09001”或“03001”，其中左侧是公司，右侧是部门

因为当我使用硬编码值运行这个查询时，它几乎是瞬间运行的。当我使用参数时，它需要几分钟。

所以我查了一下，发现了参数嗅探。所以我在开始语句之后添加了以下行。

但是，它仍然运行非常缓慢。

我的新 where 语句将是

我还希望用户具有选择所有站点的功能，这将使站点变量为“00000”，因此它不应该运行公司/部门代码检查。这个当前的 where 语句使查询运行非常缓慢。

有谁知道我做错了什么？

我构建了一个存储过程，可以在拥有许多仓库的公司中找到最短路径。该过程被系统大量使用。经过许多优化，包括内存优化表，如果我运行 sp_BlitzCache，我有 2 个警告：

1. 参数嗅探；
2. 您的缓存中有 83866 个计划，其中 100.00% 计划在过去 24 小时内创建，100.00% 在过去 4 小时内创建，100.00% 在过去 1 小时内创建。

该过程仅使用参数（无硬编码值）调用。您可以在此处找到查询计划：https ://www.brentozar.com/pastetheplan/?id=r1rW59QvN 。

我真的不明白为什么引擎会为每次执行生成一个计划以及我应该检查什么。此外，sp_BlitzCache 说我们找不到此查询的计划。造成这种情况的可能原因包括动态 SQL、RECOMPILE 提示和加密代码。我既没有动态 SQL，也没有重新编译提示，也没有加密代码。

我应该检查什么？

更新

正如 Jeroen Mostert 在评论中建议的那样，我检查了此过程对服务器的影响（感谢您的回复！），此过程使用了服务器上关于平均 IO 的前 10 个过程中的 0.66%，但它是唯一没有计划的过程，所以问题仍然存在：为什么有这么多计划？

我没有尝试在没有内存优化表的情况下运行存储过程。我不得不使用它们，因为 proc 需要像闪电一样快地运行（在某些情况下运行不到 30 毫秒）。此外，如果没有优化表内存，我没有勇气执行该过程，因为我无法在测试服务器上重现工作负载。

谢谢！

PostgreSQL 中的Prepare和Execute组合允许使用绑定参数。但是，Prepare 不会生成针对一组参数绑定优化的计划，该计划可以与一组不同的参数绑定一起重复使用。是否有人对实现此类功能有意见？有了这个，计划将针对给定的参数绑定集进行优化，但可以重用于另一组。该计划对于后续集可能效率不高，但如果使用新参数绑定重新计算计划成本，则可能会发现它是有效的。

读取和使用参数绑定值进行基数估计在 SQL Server 中称为“参数嗅探”，在 Oracle 中称为“绑定窥视”。基本上，有没有人在 PostgreSQL 中做过类似的事情。

谢谢，坎贝尔

我有一个针对一个非常大的表运行的查询，我需要对其进行计数。

如果我使用文字，查询会在几秒钟内运行，但是当我将值作为变量放入时（我需要这样做），查询需要永远并且可能会进行全表扫描。

我已经阅读了很多关于此的内容，并且我理解它最有可能与参数嗅探有关，我不能假装我理解它，我只想知道如何修复它，否则，我将不得不使用生成的查询字符串在 c# 中调用它。

此查询将在几秒钟内运行..

这需要永远

目前我们有一个数据仓库，它保存来自多个租户的数据。SQL Server 版本为 2019。所有租户数据库的相同架构和来自所有租户的数据都合并到 Datawarehouse 中。数据在租户基础上在数据仓库中进行分区。由于租户之间的数据差异很大，因此新仪表板存在参数嗅探问题。一些租户的数据少于 10000 行，一些租户的数据高达 500 万行。因此，如果执行计划是基于较小的租户构建的，则仪表板性能对大租户不利。

互联网上的建议是要求使用重新编译提示或优化提示等。但我对这个参数嗅探的基础有疑问。由于统计信息由 SQL 服务器在分区级别维护，这些统计信息是否不用于查看构建的计划是否适合新的运行时值？在执行之前，是否曾经比较基于编译时间和运行时间构建的计划的统计信息，以查看它们是否有效以及相关的计划是否有效？

好心提醒。