查询性能不佳

Question

我们有一个大型（10,000 多行）程序，通常在 0.5-6.0 秒内运行，具体取决于它必须处理的数据量。在过去一个月左右的时间里，在我们使用 FULLSCAN 进行统计更新后，它开始需要 30 多秒的时间。当它变慢时，sp_recompile 会“修复”该问题，直到夜间统计作业再次运行。

通过比较慢速和快速执行计划，我将范围缩小到特定的表/索引。当它运行缓慢时，它估计将从特定索引返回约 300 行，当它运行得快时，它估计将返回 1 行。当它运行缓慢时，它在对索引进行查找后使用表假脱机，当它运行快时它不执行表假脱机。

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

如果我更新它的统计数据，没有 FULLSCAN，它看起来更正常。如果我然后再次使用 FULLSCAN 运行它，它看起来就像我上面描述的那样。

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

proc 接受一个表值参数，参数嗅探可以发生在表值参数上吗？

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

直方图是奇怪的，还是我叫错了树？

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

我应该提到这是一个 PK IDENTITY 聚集索引。我们有两个相互通信的系统，一个是遗留系统，一个是新的本土系统。两个系统都存储相似的数据。为了使它们保持同步，当向旧系统添加事物时，新系统中此表上的 PK 会增加，即使数据没有过来（已完成 RESEED）。因此，此列中的编号可能存在​​一些空白。记录很少被删除，如果有的话。

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

Answer 1

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