我有一个存储过程，速度快，速度慢。我阅读了有关参数嗅探和查询计划的内容，并一直在分析查询计划中的哪些差异可能导致这种差异。
我意识到它似乎不是一个优化问题，参数嗅探问题。我已经使用估计的执行计划，实际执行计划和实时查询统计来比较各种情况下的计划。虽然SMSS中的返回时间从亚秒到几乎一分钟不等，但有一点是不变的 - 所有执行计划和实时查询统计信息都表明查询是/应该/快。实时查询统计信息在最近一次运行时显示0.074秒，但结果需要52秒才能返回。
流程如下：
有时候同一个查询的重复运行会很快（这让我觉得，哦，它正在从缓存加载计划并能够更快地执行，但后来我把OPTION（RECOMPILE）放在存储过程的末尾，我读了它不使用计划缓存），但有时需要同样长的时间。有时当我更改输入值时，它会更快，有时则不会。再一次，一个常数 - 计划/统计数据认为它应该是/很快。
存储过程本身并不太复杂，一个select语句在一个相当小的数据集上使用窗口进行聚合，另一个用于其他小表的连接 - 在我的测试数据集上返回的最大行数约为90。所有关键列都有索引。
我真的不认为它实际上是查询本身的性能问题，无论计划中的差异如何，我已经看到了一些细微的变化，具体取决于传入的参数，执行时间估计和实时查询统计信息是一致告诉我 - 它很快，有时候这么快，实时查询统计数据甚至不会在节点下面显示任何时间。
在某些时候用不同的参数一遍又一遍地运行它似乎很快就会回来，但只有一段时间。然后，通常只是在我感觉到的那一刻，“不管那是什么，现在似乎都很好，继续......”BAM回到Slowsville。
没有更多信息，这很难诊断。但是，听起来你可能会发生参数嗅探。