非常慢的T-SQL存储过程通过删除和重新创建来加速

正如其他回复所指出的，原因可能有很多，从执行计划到实际的SP代码，再到其他任何东西。然而，在我过去的经验中，由于"参数嗅探"，我遇到了类似的问题。谷歌一下，看看，可能会有帮助。基本上，您应该在SP中使用局部变量，而不是传入的参数。

不确定我的情况是否太不常见而对其他人有用(它涉及在存储过程中使用表变量)。但故事是这样的。

我正在研究一个问题，在大多数情况下，存储过程需要10秒，但偶尔需要3-4分钟。经过一番调查，我发现了一个规律:
这是一个存储过程，需要一个开始日期和一个结束日期，如果我运行这个一年的数据价值(这是人们通常做的)，它运行在10秒内。然而，当查询计划缓存被清除时，如果有人运行它一天(不常见的用例)，所有进一步调用1年范围将需要3-4分钟，直到我做了一个DBCC FREEPROCCACHE

我的第一个怀疑是参数嗅探。使用局部变量方法立即修复了它，然而，这只提高了很小的百分比(<10%)。
1. 在一种抓取稻草的方法中，我将原始开发人员在此存储过程中使用的表变量更改为临时表。这就是最终解决问题的方法。现在，我知道这是问题所在，我在网上做了一些阅读，并遇到了一些链接，如http://www.sqlbadpractices.com/using-table-variable-for-large-table-vs-temporary-table/这似乎符合我所看到的问题。

编码快乐! !

在没有看到SP代码的情况下很难确定。
一些建议。
默认情况下，SQL server重用存储过程的执行计划。计划在第一次执行时生成。这可能会造成问题。例如，当你第一次提供高选择性的输入时，SQL Server会根据这一点生成计划。下次传递低选择性输入时，但是SP重用旧的计划，导致执行非常缓慢。
在SP中有不同的执行路径会导致同样的问题。
尝试创建这个过程WITH RECOMPILE选项来防止缓存。
希望这对你有所帮助。

运行SQL Profiler并从网站执行它，直到再次发生。当它暂停或超时时，检查一下SQL服务器本身发生了什么。

这里有很多可能性取决于s' s过程实际做什么。例如，如果它正在插入记录，那么您可能会遇到数据库服务器需要扩展数据库和/或日志文件大小以接受新数据的问题。如果它发生在日志文件上，并且您有慢速驱动器或接近驱动器空间的最大值，那么它可能会超时。

如果它是一个select，那么这些表可能会被锁定一段时间，因为其他插入正在发生…或者它可能重用了一个糟糕的执行计划。

drop/re dance可能只是将执行延迟到SQL服务器可以赶上的程度，或者它可能会导致重新编译。

我最初的想法是它是一个索引，但进一步思考，我不认为删除和重新创建存储的prod会有帮助。

很可能是你的缓存执行计划导致的。

下次发生这种情况时，尝试使用DBCC FREEPROCCACHE来清理缓存。点击这里阅读更多内容http://msdn.microsoft.com/en-us/library/ms174283.aspx

即使这是一个反应性步骤，它也不能真正解决问题。

我建议您在SSMS中执行该程序，并检查实际的执行计划，找出导致延迟的原因。(在菜单中，点击【查看】，然后点击【包含实际执行计划】)

我认为这可能与过程本身无关，而是与您试图在数据库上执行的实际操作有关。

我不是MS SQL专家，但是当两个并发事务试图删除同一行时，它的行为与Oracle相似时，我不会感到惊讶:第一个到达删除的事务锁定行，然后第二个事务被阻塞，直到第一个事务提交或回滚。如果在过程中尝试执行此操作，则可能显示为"卡住"(直到"锁定"事务完成为止)。

您是否有长时间运行的事务可能锁定您的过程正在访问的行?