存储过程计划优化答案

【问题标题】：Stored procedure plan optimisation存储过程计划优化
【发布时间】：2013-12-18 21:06:34
【问题描述】：

我在 SQL Server 2008 R2 中有一个存储过程，它根据传入的几个参数值查询一个非常大且非常繁忙的表。我无法控制架构。

大多数时候存储过程执行得很好，但有时它似乎编译了一个非常糟糕的执行计划（我的猜测是表扫描——这对这张表来说会很疯狂）。

优化存储过程以避免这种情况的最佳方法是什么？我目前正在尝试OPTIMIZE FOR & 使用一些合理的参数值

但是，我想我可能会更好地使用USE PLAN & 只是强制执行一个我知道效果很好的执行计划（没有JOINs，表上只有 3 个索引，表大小非常一致（大！）所以我认为该计划不应该真的需要改变）。

有人有过这种事情的经验吗？什么效果最好？

【问题讨论】：

我通常首先检查参数嗅探。我花了几个小时重构查询只是为了发现使用局部变量而不是参数变量可以从一开始就修复它。我不知道它是否会帮助你，所以这不是一个答案，但这是一个不错的链接：blogs.technet.com/b/mdegre/archive/2012/03/19/…
你试过在SSMS中查看执行计划吗？它可以让您直观地了解导致性能下降的表。
您是否检查过以确保您的统计数据是最新的？如果有很多 UPDATE/INSERT/DELETE 活动，这可能是一个问题

【解决方案1】：

Grant Friitchey 是我当地 PASS 分会的朋友。

谁，你确定你没有参数嗅探吗？

这通常发生在偏斜的数据中。

如果是这样，有七种不同的方法来对抗它。查看 Grant 的幻灯片。

但关键是找到/查看图形格式的好计划和坏计划。

为什么一个比另一个好。一旦你知道发生了什么，就选择一种方法来解决它。

祝你好运

【讨论】：

【解决方案2】：

我想我已经破解了 - 问题似乎是导致基础表中没有记录的参数。

我添加了一个日期谓词 - 尽管查询实际上并不需要它，因为它使用整数升序键返回 X 个最近的记录。

当参数值没有匹配记录时，这大大减少了搜索记录的数量。

希望这是有道理的！

感谢 cmets - 很高兴能更详细地了解这些内容。

【讨论】：