存储过程超时。。放下,然后再创造,然后它又重新升起?

您是否一直在更新数据库中的统计数据?这听起来像是原始SP使用了过时的查询计划。sp_ recompile 可能会有所帮助,而不是放弃/重新创建它。

您可以做一些事情来修复/诊断此问题。

1) 定期/每天更新您的统计数据。SQL根据您的统计信息生成查询计划(思考优化)。如果它们变得“过时”,则存储过程的性能可能不如以前(尤其是在数据库发生变化/增长时)

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

这就像在电话簿中找到一个名字,如果你的电话簿上只有20或30个名字,那么阅读每个名字肯定很快。试着用一百万个名字来做,它不是那么快。

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

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

如果它运行得很快,并且(经过几个月的时间)不再运行得很快,代码也没有更改,那么底层数据似乎已经更改了。

• 我的第一个猜测是数据增长——过去几个月(或者过去几个小时,你永远不知道)添加了如此多的数据,以至于查询现在陷入困境。
• 同样,索引/数据库统计数据也可能过时。您是否打开或关闭了数据库的AutoUpdateStatistics?

同样,只有数据随着时间的推移发生了变化,这才可能有所帮助。

参数嗅探。

strange SQL server report performance problem related with update statistics