存储过程超时.. 删除，然后创建，然后再次启动？答案

【问题标题】：Stored Procedure Timing out.. Drop, then Create and it's up again?存储过程超时.. 删除，然后创建，然后再次启动？
【发布时间】：2009-10-21 16:20:38
【问题描述】：

我有一个从 MS-SQL2005 DB 调用存储过程的 Web 服务。我的 Web 服务在调用我拥有的一个存储过程时超时（这已经在生产中运行了几个月，没有超时），所以我尝试在查询分析器中运行查询，它也超时了。我决定在不更改代码的情况下删除并重新创建存储过程，然后它又开始执行了..

问题：

这通常是我的存储过程的 TSQL 中的错误吗？

-或者-

有没有人看到这个发现是存储过程的编译出了问题？

当然，也欢迎对此提出任何其他见解。

类似的：

【问题讨论】：

【解决方案1】：

您是否一直在更新数据库的统计信息？这听起来像原来的 SP 使用了一个过时的查询计划。 sp_recompile 可能会有所帮助，而不是删除/重新创建它。

【讨论】：

【解决方案2】：

您可以采取一些措施来修复/诊断此问题。

1) 定期/每天更新您的统计数据。 SQL 根据您的统计信息生成查询计划（认为优化）。如果它们变得“陈旧”，您的存储过程可能不会像以前那样执行。（尤其是当您的数据库更改/增长时）

2) 查看您的存储过程。你在使用临时表吗？这些临时表上有索引吗？大多数情况下，您可以通过查看存储过程（或它使用的表）找到罪魁祸首

3) 在“挂起”时分析您的过程，看看您的查询计划。是否有任何缺失的索引有助于防止您的过程的查询计划发疯。（寻找诸如表扫描之类的东西，以及其他最昂贵的查询）

这就像在电话簿中查找姓名一样，如果您的电话簿仅包含 20 或 30 个姓名，请确保快速阅读每个姓名。试着用一百万个名字来做，不是那么快。

【讨论】：

【解决方案3】：

这发生在我将一些存储过程从开发转移到生产后，它没有立即发生，它发生在生产数据增长几个月后。我们一直在使用函数来创建列。在某些情况下，每一行都有几个函数调用。当数据增长时，函数调用时间也随之增长。

最初的方法在测试环境中很好，但在重负载下失败了。检查proc中是否有任何函数调用。

【讨论】：

【解决方案4】：

我认为 SP 尝试使用的表已被某个进程锁定。使用“exec sp_who”和“exec sp_lock”来找出你的表发生了什么。

【讨论】：

【解决方案5】：

如果它工作得很快，（几个月后）不再工作得很快，并且代码没有改变，那么底层数据似乎已经改变了。

我的第一个猜测是数据增长——过去几个月（或过去几个小时，你永远不知道）添加了如此多的数据，以至于查询现在陷入了困境。
另外，正如 CodeByMoonlight 所暗示的那样，数据可能随着时间的推移发生了很大的变化，以至于为该过程构建的原始查询计划不再有效（尽管这假设查询计划在很长一段时间内根本没有清除和重新编译时间）。
类似地，索引/数据库统计信息也可能过时。您是否打开或关闭了数据库的 AutoUpdateSatistics？

同样，这可能仅在数据随时间发生变化的情况下才有帮助。

【讨论】：

【解决方案6】：

参数嗅探。

【讨论】：