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

问题：

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

-或-

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

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

类似：

• SQL差的存储过程执行计划性能——参数嗅探
• SQL Server 中的参数嗅探(或欺骗)

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

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

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

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

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

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

这发生在我将一些存储过程从开发转移到生产之后，它没有立即发生，它发生在生产数据增长几个月后。我们一直在使用函数来创建列。在某些情况下，每一行都有几个函数调用。当数据增长时，函数调用时间也随之增长。最初的方法在测试环境中很好，但在重负载下失败了。检查proc中是否有任何函数调用。

参数嗅探。

一天或3天前回答："奇怪的SQL服务器报告与更新统计相关的性能问题"

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

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

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

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