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

Question

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

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

这种情况是我的客户报告了一个运行缓慢的SP，我确认了，所以我添加了一个索引，运行了SP之外的代码，运行得非常快，但之后我重新运行了SP，结果没有提高。

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

Answer 1

可能是参数嗅探或PROC也许是与设置ARITHABORT叫OFF

可以显示的代码？

Answer 2

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

一些方法来解决：

WITH RECOMPILE使用，这样一个新的计划，每次

使用提示来告诉优化如何做人（指数=，稳健plan..etc）

使用

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

Answer 3

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

清除缓存执行

这将清除来自服务器的缓存坏计划（连同一切）。不完全是一个长期的解决方案，因为存储过程将来可能会再次出现问题，但这是一个很好的临时解决方案。

DBCC FREEPROCCACHE 
DBCC DROPCLEANBUFFERS 

添加WITH RECOMPILE存储过程

CREATE PROCEDURE MyExample 
WITH RECOMPILE 
AS ... 

添加WITH RECOMPILE参数存储过程使得SQL Server中创建一个新的执行计划中的每个程序运行时间。这样会伤害到性能，但如果整个程序运行速度比以前慢数千倍或超时，那么采用小的性能命中率肯定会更好。

参数嗅探

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