4

当在 SQL Server Management Studio 中执行时，我有一个查询（大约 1600 行存储为存储过程），执行大约需要 3 秒（通过添加正确的索引对其进行优化后）。

我在 C# 中为此编写了一个包装器，并为自己提供了使用 URI 来执行此查询的能力。但是，这需要 30 多秒才能执行，因此，当我将此查询作为循环的一部分运行时，浏览器会因挂起的请求过多而停止。我这样写了包装器：

try
{
   string ConString = Constants.connString;

   using (con = new SqlConnection(ConString))
   {
      cmd = new SqlCommand(sql, con);
      con.Open();
      dr = cmd.ExecuteReader();

      while (dr.Read())
      {
         ...
      }
   }
}

我的连接字符串是这样的：

Data Source={0};Initial Catalog={1};Integrated Security=True;MultipleActiveResultSets=true

我知道查询本身很好，因为我在 SSMS 中多次运行它并且它运行良好（平均不到 5 秒）。而且，我很乐意提供更多调试信息，但我不知道要提供什么。

要解决此类问题，我应该从哪里开始？

编辑：

我运行 SQL Profiler 并收集了一些统计数据。这就是我正在观察的。很奇怪，它是正在执行的确切查询。让我知道此时我还能做些什么。

在此处输入图像描述

4

4 回答 4

8

行; 最后，在这里和这里找到了答案。为方便起见，此处复制了答案。感谢原始海报Jacques Bosch，他又从这里拿走了它。不敢相信这个问题在 2004 年就解决了！

该问题似乎是由 SQL Server 的Parameter Sniffing引起的。为了防止它，只需将传入的参数值分配给在 SP 顶部声明的其他变量。

看到这篇关于它的好文章

例子：

CREATE PROCEDURE dbo.MyProcedure
(
    @Param1 INT
)
AS

declare @MyParam1 INT
set @MyParam1 = @Param1

SELECT * FROM dbo.MyTable WHERE ColumnName = @MyParam1 

GO

我从eggheadcafe.com复制了这些信息。

于 2013-02-26T23:16:56.033 回答
1

由于查询计划的缓存，查询通常在 SQL Server 管理工作室中运行得更快。在进行基准测试之前，请尝试在您的存储过程上运行 sp_recompile。这将清除查询计划。

更多细节可以在这里找到：http: //www.sommarskog.se/query-plan-mysteries.html

于 2013-02-26T23:21:43.887 回答
0

为什么不使用 XML 而不是 Result Set ？据我所知，使用 XML 比读取结果集要快得多。所以在这种情况下你应该使用这样的东西：

SELECT * 
FROM [Table Name]
FOR XML PATH('[Your Path]'), ELEMENTS XSINIL, ROOT('Your Root')

之后我认为你可以在你的项目中序列化它。

于 2013-02-26T20:44:47.913 回答
0

我曾经遇到过同样的问题，结果发现差异是ARITHABORT通过SQL管理工作室连接的设置不同造成的。.net 连接将ARITHABORT设置设置为OFF，而 SQL 管理工作室将此设置设置为ON。

如果遇到同样的问题，您可以尝试SET ARITHABORT OFF在 SQL Management Studio 中执行，然后执行您的查询。

这是一个线程，解释了为什么此设置会导致如此显着的性能差异。

于 2013-02-26T23:38:54.857 回答