对于几个场景，不是很多次，但我们很少看到在存储过程上执行 sp_recompile 可以提高性能。
作为一名 DBA，我了解在进行 sp_recompile 时所涉及的一些警告以及为什么它会提高性能。
我们的管理层一直在争论是否向 Application/DEV DBA 提供在看到上述性能问题时进行 sp 重新编译的访问权限。只是为了减少 DBA 的参与，并且 APP 开发人员可以在性能问题期间在其上运行
我很犹豫，因为我认为它会带来一些不需要的行为，有时甚至会恶化其他 proc 的性能。
我正在向您的专家寻求一般指导和经验，为什么在可能的不同情况下或在理想情况下这可能是一个坏主意。您的输入可能会帮助我进行设计，并且可能会以不同的方式解释该方法。
仅供参考-当看到参数嗅探等问题时，不仅在一个应用程序中，而且在少数其他应用程序中都认为上述是自动化的。
丢失的一件事
sp_recompile是它适用于存储过程之外的对象。从文档：如果有人在脑海中产生一个奇怪的想法，他们最终可能会影响不止一个程序：
如果开发人员已经有能力使用其他风格的重新编译提示，最好让他们在适当的时候使用这些提示，但也要让他们了解重新编译的范围的差异，以及他们如何处理参数：
一般来说，
WITH RECOMPILE应该避免——这是一种非常严厉的方法。我赞成针对重新编译提示来临时解决问题，或者当问题的其他潜在解决方案没有吸引力时。根据我的观察，许多没有经验的开发人员似乎不可避免地会偶然发现
sp_recompile,OPTION (RECOMPILE),等，并且在他们发现它神奇地DBCC FREEPROCCACHE暂时解决了他们目前面临的问题后，不幸地滥用它们，所以你犹豫不决的感觉是有道理的。我会从相反的角度说这个，但根据环境，当在恐慌模式下强制重新编译单个查询计划时，在特定过程或查询上仔细完成时，这并不是世界末日。谨慎的意思是开发人员应该只对有问题的查询计划所属的对象执行此操作，而不是垃圾邮件“重新编译按钮”来破坏所有内容，并且开发人员应该具体确定他们面临的性能问题是由于一个坏的在这样做之前执行计划（例如由于参数嗅探）。因此，应该进行一些前期培训，并且可能有选择性地允许非 DBA 开发人员“按下魔法按钮”“。我见过没有经验的开发人员安排作业在他们不知道的情况下
DBCC FREEPROCCACHE每小时运行一次的情况，他们通过对缓存的查询计划进行核对而不是解决他们的问题而导致更多的性能问题。通过像上面那样制定一些指导方针，您可以最大限度地减少引入比您解决的问题更多的问题（例如，导致更糟糕的执行计划被缓存）。
我还建议强制开发人员维护发生此类性能问题的过程/查询的运行列表，以便合格的开发人员/ DBA 在可能的情况下应用实际修复。
我想讲一个故事，也许它会对某人有所帮助。
根据我的经验；我的客户有一个包含 8-10 个表和数百列的查询。查询在一分钟内运行一百次，在某些特殊的日子，即折扣日，查询运行一千次。有时会出现参数嗅探问题，当它发生时，他们会超时，他们的网站无法打开，这是不可接受的。
那个时候我进入服务器，发现错误的计划并在一切正常之后放弃它。
顺便说一句，我重写了一个查询，但他们不能在不久的将来更改查询。
所以，我决定
OPTION (RECOMPILE)在计划指南中添加提示，它有效，但我们忘记了一些事情。特殊的日子到了，查询在一分钟内运行一千次。因此，CPU 卡在 100%。因为每次运行查询，SQL Server 都会使用更多的 CPU 来创建新的查询计划。
我同意 Erik 和 JD 的观点，我认为如果你使用这个提示，你必须非常小心和广角思考。
故事结束：那次我放弃了计划指南，整天都在寻找糟糕的计划。他们用我的版本更改了查询。现在好多了。