0

我们有一个 SQL Server 存储过程，可以直接在 SQL Manager 中正常运行，进行相当大的计算，但最多只需要 50-10 秒即可运行。

但是，当我们通过数据适配器从 .NET 应用程序调用它时，它会超时。然而超时发生在超时时间之前，我们将它设置为 60 秒，它仍然会在大约 20 秒或更短的时间内超时。

我已经用谷歌搜索了这个问题，并看到其他人注意到 SP 直接工作但通过数据适配器调用很慢的问题。

关于如何解决这个问题的任何想法？

4

3 回答 3

0

当你说它直接在SSMS中运行良好时，你的意思是执行存储过程本身运行良好，还是底层SQL运行良好？

根据您的描述，这听起来像是参数嗅探的示例。基本上，SQL Server 已经缓存了一个执行计划，该计划对于一组参数来说是最佳的，但对于大多数其他参数来说却非常糟糕。

您可以在存储过程中的查询上使用 RECOMPILE 选项来强制在每次执行时重新编译。如果不经常调用或者编译时间不长，可以利用这个技巧。

另一种解决方案是将存储过程参数复制到局部变量中并在查询中使用它们。例子：

CREATE PROCEDURE my_proc
  @var1 INT
AS
  DECLARE @_var1 AS INT;
  SET @_var1 = @var1;

  SELECT col1, col2, col3
    FROM t1
   WHERE t1.pk = @_var1;
于 2009-05-28T13:55:55.873 回答
0

确保您已检查所有超时。我不知道您使用的是 asp.net 还是 winforms，但至少此列表的前两个将适用：
超时期限未过去，但仍超时（请参阅代码）？

要检查的另一件事是您是否正确设置了参数。做错可能会破坏索引。我看到的地方是当您在对查询至关重要的 varchar 列上有一个索引，并使用普通的“AddWithValue()”或其他未明确设置的函数为该列设置参数时类型。.Net 默认会给你一个nvarchar参数，因为 .Net 中的字符串是 unicode。结果是它不能使用索引。

于 2009-05-28T14:17:13.287 回答
0

更改 SqlConnection 对象的超时属性

于 2009-05-28T16:17:00.050 回答