查询性能不佳

我们有一个很大的过程（10,000行以上），通常需要0.5-6.0秒才能运行，具体取决于要处理的数据量。在过去一个月左右的时间里，在我们使用FULLSCAN更新统计信息后，开始花费了30秒钟以上。当速度变慢时，sp_recompile会“修复”该问题，直到夜间统计作业再次运行。

通过比较慢速执行计划和快速执行计划，我将其范围缩小到了特定的表/索引。当它运行缓慢时，它估计将从特定索引返回大约300行，而当它运行速度较快时，它估计将有1行。当它运行缓慢时，在对索引执行查找后将使用表后台处理程序；而当它运行速度较快时，它将不执行表后台处理程序。

使用DBSS SHOW_STATISTICS，我在excel中绘制了索引直方图。我通常希望该图更像是“起伏的丘陵”，但相反，它看起来像一座山，最高点比该图上的其他大多数值高2x-3x。

如果我在没有FULLSCAN的情况下更新统计信息，它看起来会更正常。如果我再次使用FULLSCAN运行它，则看起来就像我上面描述的那样。

这感觉像一个参数嗅探问题，并且特别与上面的（看似）怪异的索引分布有关。

proc接受表值参数，表值参数上是否可以进行参数嗅探？

编辑：proc还需要12个其他参数，其中一些是可选的，其中两个是开始日期和结束日期。

直方图是奇数，还是我吠错了树？

我当然很愿意尝试调整查询和/或尝试调整索引。如果那是很好的解决方案，那时候我的问题更多是关于偏斜的直方图。

我应该提到这是PK IDENTITY聚集索引。我们有两个互相通信的系统，一个是旧系统，一个是新的本地系统。两个系统都存储相似的数据。为了使它们保持同步，即使将数据添加到旧系统中（完成RESEED处理），也可以在将新事物添加到旧系统中后在新系统中的此表上增加PK。因此，此列中的编号可能存在​​一些差距。记录很少删除（如果有的话）。

任何想法将不胜感激。我非常高兴收集/包含更多信息。

最终与参数嗅探有关。碰巧的是，在重建统计信息之后，就立即执行了该查询的某些奇怪形式的版本。因此，缓存的计划不能代表大多数调用。我使用了将日期参数复制到局部变量的技巧，这种方法工作得很好，对性能几乎没有影响。这并不能回答为什么直方图看起来如此“偏离”，但却可以解释我的性能问题。