执行存储过程比执行 SQL 花费的时间太长答案

【问题标题】：Executing stored procedure takes too long than executing TSQL执行存储过程比执行 SQL 花费的时间太长
【发布时间】：2014-01-06 14:50:24
【问题描述】：

我有一个存储过程，当我想使用 exec proc_name 执行它时需要 1 分钟

如果我从存储过程中复制代码，将参数声明为变量，然后执行代码需要 10 秒。

怎么了？

我在这里遗漏了什么？

我问这个是因为我使用 ADO.NET，当我想使用 ExecuteNonQuery 执行该存储过程时出现超时错误。

谢谢

【问题讨论】：

【解决方案1】：

它是由使用的次优计划引起的。你提到s.p。有参数，由于'parameter sniffing'，我也遇到过类似的问题。

检查这是否是问题的最快方法是，在 SP 内部，将输入参数复制到局部变量中，然后仅使用局部变量。

这会停止，例如以牺牲其他参数为代价优化某些参数值。

我以前在 s.p.它具有 int 参数，其中某些参数值会稍微改变控制流（以及查询的执行方式）。

【讨论】：

【解决方案2】：

启动 Sql Profiler 并比较这两个执行：额外的 50 分钟是在服务器上花费的吗？查询真的一样吗？

您可以复制实际的查询文本并手动运行它并检查执行计划。

【讨论】：

【解决方案3】：

在打开执行计划图标的情况下尝试执行过程。它会准确地告诉您哪个部分需要时间，您/我们可能可以从那里接管（建议）。谢谢

【讨论】：

【解决方案4】：

一般来说，query plans 在我们谈论即席语句与存储过程时的缓存方式不同。所以执行时间可能不同，因为选择的查询计划可能不同。

作为建议，我认为：

1/ 使与该存储过程关联的查询计划无效：

sp_recompile <procname>

2/ 从缓存中删除所有查询计划（硬方法，在 PROD 中不推荐，除非您非常了解后果）：：

DBCC FREEPROCCACHE

3/ Update statistics 用于涉及的表。

4/ 查看这两种情况的实际执行计划并找出性能瓶颈在哪里。发布一些代码，我们将为您提供更多详细信息。

【讨论】：

【解决方案5】：

选项1：在Alter State执行SP，带参数重试。

选项 2：EXEC sp_updatestats

选项 3：选项 1 失败，在查询末尾添加“选项（重新编译）”。

Eg : Select Id from Table1 Order BY Id desc option(recompile)

如果这运行得更快，则减速是由于 SQL 制定的执行计划。

【讨论】：