存储过程的执行计划突然变慢

Question

我试图了解我们在 SQL Server 2000 中遇到的一个问题。我们是一个中等事务性的网站，我们有一个名为的存储过程sp_GetCurrentTransactions，它接受一个客户ID和两个日期。

现在，根据日期和客户，此查询可以返回从零到 1000 行的任何内容。

问题：我们所经历的是，Execution Timeout Expired当特定客户端尝试执行该存储过程时，我们会突然收到许多错误（通常或类似的错误）。所以我们检查了查询，在 SSMS 中运行它，发现它需要 30 秒。所以我们重新编译存储的 proc 并且 -bang- 它现在在 300 毫秒内运行。

我已经和我们的 DBA 谈过了。他告诉我，当我们创建存储过程时，数据库创建了一个查询计划。他说对于那组参数是一个很好的计划，但是如果你向它抛出一组特定的参数，那么该计划将不是该数据的最佳计划，因此你会看到它运行缓慢。

提供给我的选项是将问题查询从存储过程移回动态 SQL，在每次运行时都会创建执行计划。

这对我来说就像是后退了一步，我觉得必须有办法解决这个问题。有没有其他方法来处理这个问题？

任何和所有的回应表示赞赏。

Answer 1

这个问题称为参数嗅探。

SQL Server 的更高版本为您提供了更多处理它的选项，例如OPTION (RECOMPILE)或OPTIMIZE FOR提示。

您可能会尝试在存储过程中声明变量，将参数值分配给变量并使用变量代替参数，因为这听起来好像大多数时候您都得到了一个相当令人满意的计划。

通常，最糟糕的计划是针对具有非常高选择性的参数编译但使用具有低选择性的参数运行的计划。

假设使用这种方法生成的计划更加健壮并且对所有参数值都满意，那么这种方法与 JNK 建议的方法相比的优势在于它不会为每次调用产生编译成本。

缺点是对于某些执行，运行时间可能比专门为这些参数值定制的计划更长，因此这是编译时间与执行时间的折衷。

Answer 2

您可以随时将 proc 调用更改为：

EXEC Database.dbo.usp_Myprocedure 'Parameter' WITH RECOMPILE

该WITH RECOMPILE部队（你猜对了！），只要运行它的执行计划的重新编译。

您还可以WITH RECOMPILE在存储过程的定义中包含：

CREATE PROCEDURE usp.MyProcedure (Parameters)
WITH RECOMPILE
AS
...