存储过程定时...删除，然后创建，它又重新启动？

Question

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

问题：

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

-Or -

有没有人看过这个，发现它是由编译存储过程的某些问题引起的？

当然，也欢迎任何其他见解。

类似：

• SQL poor stored procedure execution plan performance - parameter sniffing
• Parameter Sniffing (or Spoofing) in SQL Server

Answer 1

您是否一直在更新数据库的统计信息？这听起来像原始SP使用的是过时的查询计划。 sp _ recompile可能有助于而不是删除/重新创建它。

Answer 2

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

1）定期/每天更新统计数据。 SQL根据您的统计信息生成查询计划（思考优化）。如果它们变得“陈旧”，您的存储过程可能无法像以前那样运行良好。 （特别是当您的数据库发生变化/增长时）

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

3）在“悬挂”时分析您的程序，查看您的查询计划。是否有任何缺失的索引可以帮助您保持程序的查询计划不变。 （查找表扫描和其他最昂贵的查询等内容）

就像在电话簿中找到一个名字一样，如果您的电话簿只包含20或30个名字，请确保快速阅读每个名字。尝试使用一百万个名字，但速度不是很快。

Answer 3

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

原始方法在测试环境中表现良好但在重负载下失败。检查proc中是否有任何Function调用。

Answer 4

我认为SP尝试使用的表被某个进程锁定。使用“exec sp_who”和“exec sp_lock”来查看表格的内容。

Answer 5

如果它工作得很快，（几个月过去了）不再快速工作，代码没有改变，那么基础数据似乎有可能发生变化。

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

同样，这可能只有在数据随时间变化时才会有所帮助。

Answer 6

参数嗅探。

一天或三天前回答：“strange SQL server report performance problem related with update statistics”