运行存储过程的随机超时 - 删除重新创建修复答案

【问题标题】：Random timeout running a stored proc - drop recreate fixes运行存储过程的随机超时 - 删除重新创建修复
【发布时间】：2011-09-23 03:50:01
【问题描述】：

所以我在一个 10 年历史的系统上使用带有 .net 3.5 Web 前端的大型数据库 (30 gig) sql 2005。它有新的和旧的位

我们遇到了一个越来越频繁发生的问题。

一个存储过程（到目前为止，我们已经有 4 个不同的过程）决定它会超时。调用是从网络服务器发生的，并达到 30 秒超时并记录到我们的错误日志中。该网站使用单一登录（我知道这是错误的，但由于遗留代码无法更改）。

就在这之后，我运行了完全相同的呼叫，它需要（以我身份登录）1 秒。

问题仍然存在于这个存储过程中，直到我们删除并重新创建它，得到大量超时。每个 sp 调用都有不同的参数。就像获取与当前用户有关的所有未签名班次一样，因此当前用户作为参数传入

解决方案有效，但我真的不明白为什么。

我们的发布周期为两周，在此期间随时都会出现此错误。它发生在发布一周后的第二天，最后一次是发布后 12 天。

在每个版本中，我们对所有存储的 procs/triggers/functions/views 进行 SQL 多脚本处理，每次删除和重新创建自身。

我能想到的是存储过程执行计划已损坏/出错，删除重新创建它可以清除这一点。

我正在考虑调用sps WITH RECOMPILE 选项，这是一个禁忌吗？或可接受的方式

【问题讨论】：

【解决方案1】：

这很可能是为特定过程存储的错误执行计划的结果。

问题（简化）是 SQL Server 尝试根据传递的参数优化执行计划的使用。在某些情况下，这可能会导致可怕的性能。

这里有一些阅读资料可以进一步解释。

从好的方面来说，通过将 proc 中传递的参数复制到局部变量来修复它非常简单。

【讨论】：

【解决方案2】：

这听起来很像我一次又一次看到的问题 - 存储过程计划已从计划缓存中刷新，下次运行该过程时，恰好传入的参数导致一个计划可能对那组参数很好，但对其他组合表现很差。

如果您有“可选”参数 - 其中 NULL 或可能会传递一个值，并且您在 WHERE 子句中使用 OR 来解决这个问题，那么这通常是会导致这种事情。

WITH RECOMPILE 可能会导致大量 CPU 每次编译计划 - 如果存储过程被大量调用，那么这很容易对服务器的一般性能产生影响 - 无论这个操作系统是否超过效果一个糟糕的计划是另一回事。

一般来说，最好尝试重写查询 - 如果您使用ORs 来处理不同的参数集，那么动态 SQL（以正确的方式完成，使用带参数的 sp_executesql）会有很大帮助。

附：关于运行时运行良好的存储过程-我也看到过-我希望这取决于生成不同的计划-我一直怀疑通过例如运行SSMS 启用的SET 选项集与（在我的实例中）.Net 略有不同 - 并且计划在此实例中单独缓存。如果有人可以验证这可能会发生，我们将不胜感激！

【讨论】：

【解决方案3】：

我怀疑是存储过程直接导致了这种情况，除非它正在执行某种没有被清理的锁定/事务逻辑。即使那样，我也看不出丢弃/重新创建对此有何影响。我可能会查看 SP 正在使用的数据，并尝试使用 profiling 来跟踪它的执行路径，看看是否可以提高性能。

【讨论】：

“我看不出删除/重新创建对此有何影响”。如果性能问题是锁定/事务逻辑，它不会有任何影响，但如果问题与执行计划相关，它将产生巨大影响。重新创建 SP（ALTER 或 DROP/CREATE）将刷新当前执行计划，强制在下一次调用时生成新的执行计划。这会产生巨大的影响。