从web调用时存储过程速度较慢，从Management调用时速度较快
我有存储过程，每次从web应用程序调用它时，都会疯狂地超时。
我启动了并跟踪了那个时间的调用，最后发现了以下情况：
- 在中执行语句时，参数相同(实际上，我从SQL跟踪复制了过程调用并运行它)：它在5~6秒内完成。
- 但是当从web应用程序调用时，它需要超过30秒(在跟踪中)，所以我的网页实际上在那时超时了。
除了我的web应用程序有自己的用户之外，每件事情都是一样的(数据库、连接、服务器等)，我也尝试着与web应用程序的用户直接在工作室中运行查询，它不超过6秒。
我怎么才能知道发生了什么？
我假设这与我们使用BLL > DAL层或表适配器这一事实无关，因为跟踪清楚地表明延迟在实际过程中。这就是我所能想到的。
编辑--我在此链接中发现，ADO.NET将ARITHABORT设置为true --这在大多数情况下都是好的，但有时会发生，建议的解决办法是向存储的proc添加with recompile选项。在我的例子中，它不起作用，但我怀疑它与此非常相似。有人知道ADO.NET还做了什么或者我在哪里可以找到规范吗？
回答 8
Stack Overflow用户
发布于 2011-07-05 17:07:09
我以前也遇到过类似的问题，所以我很想看到这个问题的解决方案。亚伦·伯特兰对OP的评论导致了从web执行查询超时，但从SSMS执行时查询超时非常快。，虽然这个问题不是重复的，但答案很可能适用于你的情况。
本质上，听起来SQL Server可能有一个损坏的缓存执行计划。您正在使用web服务器执行糟糕的计划，但是SSMS使用的是不同的计划，因为ARITHABORT标志上有不同的设置(否则不会对特定的查询/存储proc产生影响)。
另一个例子请参见ADO.NET调用T存储过程将导致SqlTimeoutException，并提供更完整的解释和解决方案。
Stack Overflow用户
发布于 2012-12-11 15:29:01
我还体验到，查询在web上运行得很慢，在SSMS中运行得很快，我最终发现问题是什么叫做参数嗅探。
我的修正是将sproc中使用的所有参数更改为局部变量。
例如：改变：
ALTER PROCEDURE [dbo].[sproc]
@param1 int,
AS
SELECT * FROM Table WHERE ID = @param1 至：
ALTER PROCEDURE [dbo].[sproc]
@param1 int,
AS
DECLARE @param1a int
SET @param1a = @param1
SELECT * FROM Table WHERE ID = @param1a听起来很奇怪，但它解决了我的问题。
Stack Overflow用户
发布于 2016-09-06 13:51:58
不是垃圾邮件，而是希望对其他人有帮助的解决方案，我们的系统看到了高度超时。
我尝试使用sp_recompile设置要重新编译的存储过程，这解决了一个SP的问题。
最终，有更多的SP是定时退出的，其中许多以前从未这样做过，通过使用DBCC DROPCLEANBUFFERS和DBCC FREEPROCCACHE，超时事件的发生率已经大幅下降--仍然存在一些孤立的事件，我怀疑计划的更新需要一段时间，还有一些SPs确实表现不佳，需要重新评估。
https://stackoverflow.com/questions/6585417
复制相似问题
腾讯云开发者
