动态SQL比硬编码等效的时间长得多

Question

我有一个动态的SQL.运行大约需要4分钟.如果我改为使用SQL的输出并运行它,则需要大约20秒.为什么会出现差异？我知道在动态版本中构建SQL会花费一些时间,但我无法想象它的价格昂贵.

有人有主意吗？这两个查询应该是相同的,所以我怀疑它是查询计划缓存的奇怪之处,但实际上并没有多少想法.

编辑: 通过输出来澄清我的意思.

在动态SQL中,最后一行是

EXEC sp_executesql @myQuery,
    N'@var1 INT,
    @var2 INT,
    @var2 INT',
    @var1,
    @var2,
    @var3

我获取了myQuery的值并将其放在自己的SQL文件中.那是在20秒运行,而使用执行的动态需要4分钟.

编辑2 我删除了参数.我得到了有趣的结果.动态SQL语句看到了性能提升.硬编码版本的性能受到了极大的打击.两者现在差不多了.

Answer 1

我将假设您使用的是Microsoft SQL Server(您只标记了您的问题"sql").

在某些情况下,不同的参数值可能导致不同的优化计划.然后缓存该优化计划,并在下次使用不同参数值执行查询时使用.但优化计划不是后续参数值的最佳计划.

所以是的 - 在某些情况下,与没有参数化运行相同的查询相比,使用参数化查询会导致性能不佳.

如果您无权发布您的代码,我们无法知道这是否适用于您的情况.

我尊重您不能这样做 - 通过发布到StackOverflow,您隐式地使用知识共享许可证许可您的代码和/或单词.但是,除非他们同意,否则分享由您的雇主拥有的代码是不合适的.

Answer 2

正如Bill Karwin所说,这可能是一个"参数嗅探"问题.尝试包括以下内容:

OPTION (RECOMPILE)

在SQL查询结束时.

Answer 3

如果您使用的是 SQL Server 2008 或更高版本，请使用 OPTIMIZE FOR UNKNOWN 查询提示。将以下内容添加到动态查询的末尾：

OPTION (OPTIMIZE FOR (@var1 UNKNOWN, @var2 UNKNOWN, @var3 UNKNOWN))

尝试更改输入或输出 @var1、@var2 和 @var3 的三个输入。是的，如果查询优化器试图对真正特别的东西使用统计信息，它真的会很昂贵。如果您的一个或多个变量是相当可预测的，则针对特定值优化这些变量，并针对未知值优化其余变量。查看此链接了解更多详情。

需要明确的是，这可能是上面 ninjaPixel 所指出的参数嗅探问题。 OPTIMIZE FOR UNKNOWN可以为您提供比重新编译每个查询更好的结果，因为查询优化器依赖统计信息来进行编译。