问题标签 [parameter-sniffing]

我遇到了针对 SQL Server 2008 R2 运行的实体框架 (4.2) 生成的简单 SQL 查询的一些主要性能问题。在某些情况下（但不是全部），EF 使用以下语法：

在其他情况下，只需执行原始 SQL，并将提供的参数烘焙到查询中。我遇到的问题是使用 sp_executesql 执行的查询忽略了我的目标表上的所有索引，导致查询性能极差（通过检查 SSMS 中的执行计划确认）。

经过一番研究，听起来这个问题可能是由“参数嗅探”引起的。如果我像这样附加 OPTION(RECOMPILE) 查询提示：

使用目标表上的索引并且查询执行得非常快。我还尝试切换用于禁用数据库实例（http://support.microsoft.com/kb/980653）上的参数嗅探（4136）的跟踪标志，但这似乎没有任何效果。

这给我留下了几个问题：

1. 无论如何将 OPTION(RECOMPILE) 查询提示附加到实体框架生成的 SQL 中？
2. 有没有办法阻止实体框架使用 exec sp_executesql，而是简单地运行原始 SQL？
3. 还有其他人遇到这个问题吗？还有其他提示/提示吗？

附加信息：

1. 我确实通过 SSMS 重新启动了数据库实例，但是，我将尝试从服务管理控制台重新启动服务。
2. 参数化设置为 SIMPLE (is_parameterization_forced: 0)
3. 针对临时工作负载进行优化具有以下设置
   • 值：0
   • 最小值：0
   • 最大：1
   • 使用价值：0
   • is_dynamic: 1
   • is_advanced: 1

我还应该提到，如果我在使用以下脚本启用跟踪标志 4136 之后通过服务管理控制台重新启动 SQL Server 服务，似乎实际上清除了跟踪标志......也许我应该以不同的方式这样做......

更新：我提出了在未来版本的 EF 中实施提示控制的建议。去这里投票吧。

我有一个问题，我的一个实体框架 (EF) 查询在 Sql Server 中执行需要很长时间，尽管当我将生成的 TSQL 复制并粘贴到 Sql Server Management Studio (SSMS) 中时，它运行得非常快。经过一番调查，我发现我遇到了参数嗅探问题，修复它的正确方法是插入许多查询提示之一（OPTIMIZE FOR、RECOMPILE 等）。如何将这些提示插入到我的 EF 查询中？

来自不同角度的相关问题在这里、这里和这里。

我有以下代码重复运行存储过程。当我从字面上运行 SQL 语句时，它工作得很好，所以我创建了一个存储过程来封装我正在做的事情。

然后，我想知道每个调用生成了多少行，所以我稍微更改了 SP 以@@rowcount作为输出参数返回。我不能使用 DataContext 来执行带有输出参数的命令，所以我不得不将 for 循环中的上述代码更改为以下内容：

这可行，但它的运行速度比其他查询慢得多。我认为这可能是参数嗅探的情况，所以我将其更改为CommandType.Text并使用了 string EXEC Session_Aggregate ... WITH RECOMPILE。但在这种情况下，我不断收到@session未定义 out 参数的错误。无论如何，查询现在几乎没有运行，即使 SQL 命令在 SSMS 中运行时间 < 1 秒。

这是存储过程，以防万一任何人都可以帮助弄清楚发生了什么，或者可以找出加快速度的方法。我还将就如何正确描述这里发生的事情提出建议。我CommandType.StoredProcedure什至看不到 VS 发送到 SQL 的实际命令。

编辑：无论原始查询的执行计划如何，通过创建一个临时表都大大加快了它的速度。我以为 SQL 会通过分析查询来做到这一点，但我可能错了。此外，我发现了OPTIMIZE FOR UNKNOWN在新版本的 SQL Server 中，当执行计划针对大量不同大小的数据时，可以减轻参数嗅探的影响。

额外的简化：将 SP 拖到您的 DBML 文件中，您可以执行以下操作：

我在 SQL Server 2012 中有一个多租户数据库，其中每个租户的行都由一tenant_id列标识（也称为共享数据库、共享架构方法）。一些租户，尤其是较新的租户，行数很少，而另一些则很多。

SQL Server 的查询优化器通常会根据第一次执行期间提供的参数构建查询计划，然后将这个计划重新用于所有未来的查询，即使提供了不同的参数。这称为参数嗅探。

我们的数据库存在的问题是 SQL Server 有时会根据指向较小租户的参数构建这些计划，这对于该租户来说效果很好，但是当它将缓存的计划重新应用到较大的租户时，它会灾难性地失败（通常是定时事实上）。通常，只有当我们的一个较大的租户与我们联系并告知我们遇到超时错误时，我们才会发现这种情况，然后我们必须进入系统并手动刷新所有查询计划以更正它。

您可以使用查询提示来防止 SQL Server 缓存查询计划 ( OPTIMIZE FOR UNKNOWN)，但这会导致一些额外的开销，因为每次调用查询时都会重新生成查询计划。另一个问题是我们使用的是实体框架，它无法指定OPTIMIZE FOR UNKNOWN查询的提示。

所以问题是——多租户数据库在参数嗅探方面的最佳实践是什么？有没有一种方法可以在数据库范围内禁用参数嗅探，而不必在每个查询中都指定它？如果是这样，这甚至是最好的方法吗？我应该以其他方式对数据进行分区吗？还有其他我没有想到的方法吗？

我遇到了一个问题，其中包含大约 70 个参数的更新查询有时会超时。根据一些研究，我相信这是由于数据包嗅探。我看到在较新版本的 SQL Server 中，我可以使用该Option(recompile)子句，但在我的情况下这不起作用，因为我使用的是服务器 2000。

我正在使用sqlhelper.executeNonQuery而不是存储过程。

当对表运行 sp_recompile 时，我知道依赖于该表的所有存储过程和触发器都将被重新编译。

我不明白的是 SQL Server 用于此重新编译的参数。我看不出参数嗅探会如何影响这里。它是否使用类似于 OPTIMIZE FOR UNKNOWN 的东西来编译一个“通用”的执行计划？

我觉得我错过了一些非常明显的东西。

有人对此有了解吗？

设置：

使用 SQL Server 2008 R2。

我们有一个间歇性运行很长时间的存储过程。我想测试一个参数嗅探导致查询引擎选择错误计划的理论。

问题：

如何将查询的执行计划从一个数据库复制到另一个（测试）数据库？

笔记：

我完全意识到这可能不是参数嗅探问题。但是，如果可能的话，我想完成创建测试计划并使用它的动作。因此，请不要让我发布代码和/或表模式，因为此时这无关紧要。

SQL Server 2014 的“Hekaton”内存表优化宣称，“存储过程中业务逻辑的本机编译”。然而，由于 SQL Server 2012 及更早版本中的“参数嗅探”（请参阅​​此处和此处）存在问题，我一直被迫使用OPTIMIZE FOR UNKNOWN（或其等效项）设计大部分存储过程。这有效地防止了查询计划被缓存，并强制 SQL Server 在每次运行时重新编译/重新优化查询。Hekaton 的大部分性能提升来自于本机编译查询的重用，SQL Server 2014 是否可以解决参数嗅探问题，以便我可以实际使用编译查询？

我读过很多关于参数嗅探的文章，但不清楚这是好是坏。谁能用一个简单的例子来解释这一点。

有没有办法自动检测分配给特定语句的错误计划？

提前致谢。

这可能是这个问题的重复，尽管我认为我的例子更深入一些，我希望得到更明确的答案。我试图理解为什么运行简单查询的option(recompile)性能更好。

不运行时option(recompile)（无论我运行多少次）

相同的查询，但option(recompile)最后添加

如果我不在查询中使用变量，而是使用常量，那么一切都很好。我认为这与参数嗅探有关，但问题是为什么？还有什么是离开option(recompile)生产代码的缺点？

我还做了一些从应用程序中运行查询的诊断测试，并且似乎option(recompile)总是更快的结果。

更新：运行exec sp_updatestats没有效果，并且选择option(recompile)仍然执行得更好。

感谢您的时间。