SQL Server 查询从代码运行的时间比从 Management Studio 运行的时间长答案

【问题标题】：SQL Server query runs more time from code than from Management StudioSQL Server 查询从代码运行的时间比从 Management Studio 运行的时间长
【发布时间】：2023-03-10 03:39:01
【问题描述】：

我有一个存储过程，我知道它可能需要一些时间才能执行。

当我从 SQL Server Management Studio 运行它时，大约需要 12-15 分钟才能完成，这很好。

但是当我从我的 C# asp.net Web 应用程序运行它时，它会在 40 分钟后崩溃，但仍然没有完成。

两次运行之间的区别是什么？如何修复它以从我的应用程序运行？

【问题讨论】：

Slow in the Application, Fast in SSMS? Understanding Performance Mysteries 参数嗅探或并发访问和阻塞
您是否尝试过使用 Profiler 捕获时间？
是的，我做到了，但没有太大帮助......
可能在连接字符串中？
您确定它在存储过程调用时崩溃了，还是之后可能崩溃（一旦您从 SQL 检索数据）？你在（任何循环）之后对数据做了什么？

标签： c# asp.net sql-server

【解决方案1】：

为了解决崩溃问题，我们增加了 IIS 中的超时时间。 @Apostrofix 发布了 this link 一个我以前不熟悉的意外解决方案。

这篇文章的引用是：

大多数情况下推荐的修复方法（尽管它取决于您的查询和存储过程的结构）是不使用您的参数直接在您的查询中，而是将它们存储到局部变量中然后在查询中使用这些变量。

【讨论】：

建议的修复（将参数存储到局部变量中）使我的 SP 的执行时间从 4'30'' 下降到 15'' !!

【解决方案2】：

嘿，您可以尝试在 web 配置 中增加连接字符串的超时时间：只需更改超时键的值即可。

<add key="Inf:DatabaseCommandTimeoutSeconds" value="20" />

【讨论】：

我知道我可以增加超时时间，但我不希望查询运行那么久，这样做是一个不好的解决方法...
你能粘贴你的数据库查询吗？告诉我你正在处理多少数据？也许我可以优化查询。
好的。因此，您可以考虑自己优化查询。使用 SSMS 中的“包括实际执行计划”选项来查看每个查询部分使用的时间。