我在另一个获得了不错回答的论坛上提出了这个问题，但是我想看看这里是否有人有更多的见识。

问题是，Web应用程序中的一个页面进入存储过程调用时会超时，因此我们使用Sql Profiler或者应用程序跟踪日志来查找查询，然后将其粘贴到Management Studio中以进行计算。我们为什么它运行缓慢。但是我们从那里运行它，它就一直燃烧着，每次返回不到一秒钟。

我的特殊情况是使用ASP.NET 2.0和Sql Server 2005，但我认为该问题可能适用于任何RDBMS系统。

解决方案

回答

尝试更改SelectCommand超时值：

DataAdapter.SelectCommand.CommandTimeout = 120;

回答

到目前为止，这是我从研究中学到的东西。

.NET发送的连接设置与我们登录Management Studio时获得的设置不同。如果我们通过Sql Profiler嗅探连接，则将看到以下内容：

-- network protocol: TCP/IP  
set quoted_identifier off  
set arithabort off  
set numeric_roundabort off  
set ansi_warnings on  
set ansi_padding on  
set ansi_nulls off  
set concat_null_yields_null on  
set cursor_close_on_commit off  
set implicit_transactions off  
set language us_english  
set dateformat mdy  
set datefirst 7  
set transaction isolation level read committed

我现在将这些设置粘贴到登录sql server时运行的每个查询的上方，以确保设置相同。

对于这种情况，在断开并重新连接后，我分别尝试了每个设置，发现将arithabort从关闭更改为打开可以将问题查询从90秒减少到1秒。

最可能的解释与参数嗅探有关，这是Sql Server用来选择认为最有效的查询计划的技术。当我们更改连接设置之一时，查询优化器可能会选择其他计划，在这种情况下，它显然选择了错误的计划。

但是我并不完全相信这一点。更改此设置后，我尝试过比较实际的查询计划，但尚未看到差异显示任何更改。

在某些情况下，关于arithabort设置是否还有其他可能导致查询运行缓慢的问题？

解决方案似乎很简单：只需将set arithabort放在存储过程的顶部。但这可能会导致相反的问题：更改查询参数，突然间，"关闭"比"打开"运行速度更快。

目前，我正在运行"带有重新编译"过程，以确保每次都重新生成计划。这份特定的报告可以，因为重新编译可能要花一秒钟的时间，而且在需要1到10秒的时间才能返回的报告中也不太明显(这是一个怪物)。

但这不是其他查询的选择，这些查询运行频率更高，并且需要在几毫秒内尽快返回。

回答

首先在暂存盒中进行测试，然后在SQL Server的服务器级别上对其进行更改

declare @option int
  
  set @option = @@options | 64
  
  exec sp_configure 'user options',
  @option
  
  RECONFIGURE

回答

我们是否打开了ASP.NET跟踪？我有一个实例，问题出在的不是SQL存储过程本身，原因是该过程返回了5000行，而该应用正试图使用​​导致该问题的那5000个项目创建数据绑定的ListItems。

我们可能还会通过跟踪调查Web应用程序功能之间的执行时间，以帮助跟踪情况。

回答

我们可以尝试使用sp_who2命令查看有问题的进程在做什么。这将向我们显示它是否被另一个进程阻止，或者是否使用了过多的cpu和/或者io时间。

回答

我在使用SQL报告服务时遇到了同样的问题。
尝试检查变量类型，
我正在向SQL发送不同类型的变量，例如在应该发送varchar的地方
是整数或者类似的东西。
在Reporting Service和SQL的存储过程中同步变量的类型之后，我解决了该问题。

回答

我也遇到过类似的问题。尝试在sproc create上设置" WITH RECOMPILE"选项，以强制系统在每次调用时重新计算执行计划。有时，查询处理器会在带有许多分支或者case语句的复杂存储过程中感到困惑，而只是提出一个真正次优的执行计划。如果这似乎可以"解决"问题，则可能需要验证统计信息是否最新和/或者分解存储过程。

我们还可以通过分析存储过程来确认这一点。当我们从SQL Managment Studio执行它时，IO与从ASP.NET应用程序对其进行概要分析时相比如何。如果他们很多的话，那只会强化它制定了糟糕的执行计划。