SQL Server性能 - 运行即席查询与在存储过程中编译

Question

存储过程运行速度非常慢（> 60秒）是否有任何逻辑上的原因，但如果我运行与常规SQL脚本完全相同的代码，它将在不到3秒的时间内执行？

以我的思维方式，他们应该运行相同，但这不是我所看到的。我怀疑还有其他事情发生，但想知道是否还有其他人看过类似的东西。

情况是我的客户报告了一个运行缓慢的SP，我确认了，所以我添加了一个索引，在SP之外运行代码并且运行速度非常快，但后来我重新运行了SP并且它没有改进

我也放弃并重新创建SP以防万一，但不知何故，似乎每次SP运行时它可能会使用旧的执行计划？

Answer 1

可以是参数嗅探，也可以通过将ARITHABORT设置为OFF来调用proc

你可以显示代码吗？

Answer 2

这可能是一个缓存的执行计划问题..我已经看到它发生了很多次，存储过程将超时但是从查询分析器运行相同的SQL将立即返回。我知道目前解决这两个问题的两种简单方法：

清除执行缓存

这将清除服务器中的错误缓存计划（以及其他所有内容）。这不是一个长期解决方案，因为存储过程将来可能会再次出现问题，但这是一个很好的临时解决方案。

DBCC FREEPROCCACHE
DBCC DROPCLEANBUFFERS

将WITH RECOMPILE添加到存储过程

CREATE PROCEDURE MyExample
WITH RECOMPILE
AS ...

将WITH RECOMPILE参数添加到存储过程使SQL Server每次运行该过程时都会创建一个新的执行计划。这会损害性能，但是如果整个过程运行速度慢几千倍或像之前那样超时，那么获得较小的性能肯定会更好。

参数嗅探

在存储过程中查看有关参数嗅探的article。根据该文章，您可以稍微修改存储过程代码以禁用MS SQL的参数嗅探，这也可能有助于解决问题。

Answer 3

为存储过程缓存单个执行计划。如果基于参数，过程通常会产生截然不同的结果/搜索模式，则可能使用次优缓存执行计划来解析过程查询。

一些修复方法：

使用WITH RECOMPILE以便每次都使用新计划

使用提示告诉优化器如何表现（index =，robust plan..etc）

重新设计程序/系统，以确保与参数值无关的类似访问模式。