慢查询ColdFusion,SQL Server,依赖于空格

Question

我们有一个问题,我们从ColdFusion 9调用SQL Server 2005.我无法发布原始查询但它不是问题的焦点,我已经发布了导致问题的相关组合.

我们有一个查询,它是以下示例查询的一个更复杂的版本,其中something列是主键.value参数不会更改.由于我们无法理解的一些奇怪的原因,这个查询需要大约20秒才能运行....

<cfquery result="q" datasource="dsn">
  SELECT something
  FROM somewhere
  WHERE something = <cfqueryparam cfsqltype="cf_sql_integer" value="#value#"/> 
</cfquery>

请注意,如果您突出显示上面的源代码的最后一行,则在cfqueryparam标记之后有一个空格.

以下查询完全不同,因为我相信您可以自己查看,需要15毫秒才能运行.

<cfquery result="q" datasource="dsn">
  SELECT something
  FROM somewhere
  WHERE something = <cfqueryparam cfsqltype="cf_sql_integer" value="#value#"/>
</cfquery>

cfqueryparam之后没有空格.但是,在末尾添加两个空格也会产生15 ms.如果我们然后返回到最后一个空格再次给我们大约20秒的结果.

我们已经检查了Java和SQL Server之间的数据库驱动程序日志,似乎没有什么不寻常的.这可能发生什么？

---

编辑

我们在SQL Server上运行了分析,它表明对于具有单个空间的查询,它使用的是具有零或多个空格的不同缓存执行计划.SQL Server缓存查询的执行计划.它还使用完整的文字查询作为标识符.因此,当我们发送其他查询时,正在使用不同的执行计划.

进一步

其中一个执行计划看起来正在查找其中一个子选择上的错误索引,不清楚为什么SQL Server已经决定了这个备用执行计划,或者为什么看起来其中一个索引是错误的.

跟进

对于那些可能导致糟糕的执行计划感兴趣的人,后续问题发布在这里:SQL Server 2005缓存了一个永远不会工作的执行计划

Answer 1

这可能是前几天Railo 论坛上突然出现的一些事情的症状（奇怪的巧合）。

首次运行慢速版本的查询时使用的参数值的性质有可能导致创建一个对于该特定值“方便”的执行计划，但对于更典型的后续值，该计划小于理想的。相反，当第一次运行第二个查询时，作为参数传递的值更典型地反映了查询的调用方式，因此执行计划更适合大多数其他值。

我个人没有见过这种情况发生，但我已经读过很多次了。听起来确实像你所看到的那样。

如果可能的话，通过明确的 SQL Server 缓存来测试这一点，然后使用导致编译“坏”计划的值重新运行查询，您应该会看到类似的行为。

这不是解决方案，但它会证明这可能是原因，并允许您解决不同值的计划差异的可能根本原因。

这个实验显然是基于知道第一次调用查询时的参数值是什么，这是......如果你确实知道它们，那对你来说是偶然的。