关于sp_recompile的一般问题

Question

对于几种场景，我们很少见过在存储的proc上执行sp_recompile来提高性能。

作为一名DBA，我理解在执行sp_recompile时所涉及的几个注意事项，以及为什么它会在提高性能方面发挥作用。

在我们的管理层中，对于提供Application/DEV DBA对do sp重新编译的访问权限，当他们看到上面这样的性能问题时，一直存在争论。这样就可以减少DBA的参与，并且APP devs可以在perf问题上运行。

我非常犹豫，因为我认为它会带来一些不想要的行为，有时甚至会使其他过程的表现恶化。

我正在寻找一般的指导和经验，从您的专家，为什么这可能是一个不好的想法，在可能的不同情况下，或当它可以是理想的。您的输入可能会帮助我进行设计，并可能以不同的方式解释这种方法。

FYI- -当看到参数嗅探之类的问题时，FYI不仅仅是一个应用程序，而是很少被认为是自动化的应用。

Answer 1

关于sp_recompile的一件事是，它在存储过程之外的对象上工作。从医生那里：

当前数据库中存储过程、触发器、表、视图或用户定义函数的限定或非限定名称。

如果有人脑子里有一个奇怪的想法，他们最终可能会影响到不止一个程序：

如果对象是表或视图的名称，则所有引用表或视图的存储过程、触发器或用户定义函数都将在下次运行时重新编译。

如果开发人员已经有能力使用其他类型的重新编译提示，那么最好让他们在适当的时候使用这些提示，但也让他们了解重新编译的内容和范围差异，以及他们如何处理参数：

对于至少运行Server 2008 build 2746 (带有累积更新5的Service 1)的实例，使用选项(重新编译)比使用重新编译具有另一个显著的优势:只有选项(重新编译)才能启用参数嵌入优化。

一般来说，应该避免使用WITH RECOMPILE --这是一种非常困难的方法。我是倾向于以重新编译提示为目标，要么暂时解决一个问题，要么当一个问题的其他潜在解决方案没有吸引力时。

Answer 2

从我的观察来看，许多缺乏经验的开发人员似乎不可避免地遇到了sp_recompile、OPTION (RECOMPILE)、DBCC FREEPROCCACHE等问题，不幸的是，当他们发现它神奇地暂时解决了他们目前面临的问题后，他们会对他们进行滥用，所以你的犹豫不决的感觉是有道理的。

不过，我将从相反的角度说这一点，但取决于环境，在恐慌模式下，当在特定过程或查询上仔细执行时，强制重新编译单个查询计划时，这并不是世界末日。谨慎的意思是，开发人员只应该对有问题的查询计划所属的对象这样做，而不应该垃圾处理“重新编译按钮”来对所有内容进行核弹，而且开发人员在这样做之前应该具体地确定他们所面临的性能问题是由于执行计划错误(例如，由于参数嗅探造成的)。因此，应该有一些预先培训和可能的选择性，非DBA开发人员被允许“按魔术按钮”。我曾见过一些情况，即没有经验的开发人员将作业安排在他们不知道的每小时运行DBCC FREEPROCCACHE的情况下，他们使用缓存的查询计划而不是解决他们的问题，从而导致了更多的性能问题。

通过制定上面所述的一些指导方针，可以将引入比解决问题更多问题的机会降到最低(例如，导致更糟糕的执行计划被缓存)。

我还建议强制开发人员在出现这些类型的性能问题时维护过程/查询的运行列表，以便在可能的情况下由合格的开发人员/ DBA应用实际的修复。

Answer 3

我想讲一个故事，也许它会对某人有帮助。

根据我的经验，我的客户有一个查询，其中包括8-10个表和上百个列。查询立即运行100次，在某个特殊的日子，即折扣日，查询运行了上千次。有一个参数嗅探问题不时发生，当它发生时，他们得到一个超时，他们的网站无法打开，这是不可接受的。

那一次，我进入服务器，发现糟糕的计划，并放弃它之后，一切正常。

顺便说一下，我重写了一个查询，但是他们不能在不久的将来更改查询。

因此，我决定在计划指南中添加OPTION (RECOMPILE)提示，这是可行的，但我们忘记了一些东西。

特别的一天已经到来，查询马上就会运行上千次。所以，CPU保持在100%。因为每次运行查询，Server都会使用更多CPU来创建新的查询计划。

我同意Erik和J.D.的观点，我认为如果你使用这个提示，你必须非常小心和广角思考。

故事的结尾:那次我放弃了计划指南，整天在寻找糟糕的计划。他们用我的版本更改了查询。现在更好了。