问题标签 [parameter-sniffing]

我有以下代码：

我得到以下查询：

您会看到，实际值 1 和 3 没有插入到查询中，而是作为参数传递，这通常会导致选择次优的执行计划。

我可以以某种方式使 Ling-To-Sql 发射WHERE [t0].[State] = 1 OR [t0].[State] = 3吗？

创建了以下脚本来加载用户帐户。在管理工作室的初始测试中使用参数字符串作为用户名。奇怪的是，在我从参数字符串更改为字符串文字后，查询速度减慢了 20 秒。这不是通常用于参数嗅探的另一种方式吗？我已经尝试过 DBCC FREEPROCCACHE 并通过设置一些本地变量来创建存储过程，但这并没有加快查询速度。有什么建议么？

我有一个 sql 查询，在 ssms 中运行大约需要 15 秒，但是当我在 ssrs 中运行时，需要 5-7 分钟。从我读过的所有内容来看，这似乎来自“参数嗅探”，所以我在查询中声明了变量以绕过它，但是我仍然遇到多个参数的问题。

我试过这个：https ://social.msdn.microsoft.com/Forums/sqlserver/en-US/ee0e8b0c-44ae-4558-9b7e-d287dacfb8a5/multi-value-parameter-sniffing?forum=sqlreportingservices

和：

我传入的参数是：@Places

如果我在运行报告时只选择一个位置，则此方法有效，否则会引发错误：

有关此错误的详细信息，请导航到本地服务器计算机上的报告服务器，或启用远程错误 ---------------------------- 查询数据集“dataset1”执行失败。(rsErrorExecutingCommand) ---------------------------- 报告处理过程中发生错误。(rsProcessingAborted)

ParseValues 函数来自http://visakhm.blogspot.in/2010/02/parsing-delimited-string.html

有人有其他想法吗？

我相当确定向表值参数添加参数嗅探几乎没有价值，但是我想知道是否有人可以证实这一点？

（INT_LIST 是用户定义的表类型，它是 INT 类型的单列）

由于 SQL Server 中的参数嗅探，我们遇到了性能问题。我们的应用程序将 NHibernate 与 LINQ 提供程序一起使用。

我正在寻找一种将例如“OPTION(RECOMPILE)”添加到该特定 SQL 查询的方法。我现在可以为此使用拦截器，但我希望它只添加到某些 IQueryable 查询中。所以不是我所有的休眠查询，因为那样我会失去查询计划缓存的优势。

也欢迎使用 NHibernate 解决 1 个特定查询的参数嗅探的其他选项。

我正在使用 SQL Server 2012。最近我的所有存储过程都存在性能问题，但过程中的代码运行速度非常快。

我发现了一些关于参数嗅探的东西，所以我使用定义局部变量技术作为我所有程序的解决方法。

我问自己，为什么在我的所有程序中都会发生这种情况。我唯一的猜测是，那是因为我所有的程序都使用一个 OPTIONAL 参数。

这是我所有程序的标题

我对吗？或者你有什么其他想法？

最近，我的一位从事 SQL 开发的同事遇到了这样一个问题：一个过程在所有环境中运行良好，但在生产环境中，它拥有最多的资源。参数嗅探的典型案例，但分析器表明整个过程中只有一个查询需要非常多的时间来执行：

由于我偏向于开发（我几乎没有管理经验），我建议应该重写这个查询：

• 替换LEFT JOIN (SELECT DISTINCT ...)为NOT EXISTS (SELECT 1 ...)

• 在表上放置适当的索引usr.tpt_udef_article_grouping_buffer（SSMS 建议在过程之外运行查询时减少 95% 的工作量）

此外，来自该过程的多个查询共享相同的模式。

我知道参数嗅探与（重新）创建后第一次运行程序时的计划构建更相关，我认为它也受到高圈复杂度的青睐。

我的问题是：

过程中查询的编写方式（从一开始就糟糕的执行计划）有利于参数嗅探的出现还是只会恶化它们的效果？

当我的一个查询的执行时间比预期的要长得多时，我遇到了参数嗅探。当我更深入地研究这个问题时，我开始知道：

当第一次执行查询时，它（SQL Server）为该查询和其他 n 次执行相同的查询创建执行计划，如果第一次执行的结果集差异很大，则出现参数嗅探问题”。

这是在我的场景中。

现在我的问题是，在这些情况下，是否有任何方法或解决方法可以克服 SQL Server 中的参数嗅探？

• 我知道通过运行sp_updatestats我可以验证它是否正在发生。

• 而且我知道要解决这个问题，我需要监控过程缓存，我可以通过query_hash这些query_plan_hash字段sys.dm_exec_query_stats来做到这一点。

• 我不想RECOMPILE在SET变量部分中使用，因为这会在每次执行查询时创建新的执行计划。

但是，我不想通过在查询本身中做一些事情来验证问题，而是指例如“在运行时检测问题并仅在需要时创建新的执行计划（不是每次）”。

我经常遇到参数嗅探问题，所以每一个有用的建议和帮助都将不胜感激。提前致谢！

我正在尝试使用sp_executesql但在另一个存储过程中调用存储过程（带有输出变量）。我写了以下内容，但仍然无法理解该错误的含义

这将从 web 服务代码中调用：

这里obj和params是nvarchar(max)

的定义sp1是：

的定义sp2：

我在这里返回@Newval

我得到的错误：

消息 102，级别 15，状态 1，第 1 行
',' 附近的语法不正确。

同样在 2 中代替execstatement ，我尝试了以下操作：

导致同样的错误。

也会导致同样的错误。

我需要在 sp1 中动态选择存储过程，params 是nvarchar(max)一串参数及其值，其中一些是 varchar 并以“值”格式嵌入，但这个字符串很好，因为我可以调用底层 sp2有了这个。

附加信息，它有帮助。

在此@params 中是最终 sp 的键和 vlaue 对的组合。像：
'@key1="a",@key2="b"'
等等，我无法预定义@params，但它是动态的，当我运行它时它工作正常

格式，而整个名称，参数嵌入在@sql中

我有一个存储过程 (SP)，其中传入了一个表值参数 (TVP)。SP 中的相同代码执行速度比 SP 外部慢很多。

我查看了执行计划，它们非常不同。

起初这似乎是参数嗅探的标志，但这是针对 TVP 的！哪个工作有点不同（我不太确定 - 显然没有嗅探TVP的？）。

无论如何，如果我创建一个新的本地 TVP 并将行插入其中，那么我会得到一个很好的执行计划！

到底是怎么回事？

编辑我尝试了许多查询优化器提示，但它们不起作用。包括建议的重复问题中的一个。这几乎就像糟糕的计划（缓慢的计划），在估计的行数方面是正确的。快速计划对行数的估计不正确。