我可以停止调用 sp_reset_connection 以提高性能吗？

Question

我的探查器跟踪显示在每个 sql 批处理或过程调用之间都会调用 exec sp_reset_connection 。有原因，但是我可以阻止它被调用吗？我确信这是不必要的，以提高性能？

更新： 我认为这可以提高性能的原因有两个：

1. SQL Server 不需要重置连接状态。我认为这将是一个相对可以忽略不计的改进。
2. 减少了网络延迟，因为客户端不需要发送 exec sp_reset_connection、等待响应，然后发送它真正想要执行的任何 sql。

第二个好处是我感兴趣的，因为在我的架构中，客户端有时距离数据库有一定距离。如果每个 sql 批处理或 rpc 都需要两次往返，则任何网络延迟的影响都会加倍。消除这种双重调用可能会提高性能。

是的，我可以做很多其他事情来提高性能，例如重新设计应用程序，而且我非常热衷于解决问题的根本原因，但在这种情况下，我只想知道这是否可能 以防止调用 sp_reset_connection。然后我可以测试是否有任何性能改进，并正确评估不调用它的风险。

这引发了另一个问题：与 sp_reset_connection 的网络通信是否真的像我上面概述的那样发生？即客户端是否发送exec sp_reset_connection，等待响应，然后发送真正的sql？或者这一切都归为一块？

Answer 1

如果您使用 .NET 连接到 SQL Server，则从 .NET 3.5 开始禁用额外的重置调用 - 请参阅 此处。 （该财产仍然存在，但它没有任何作用。）

我想微软意识到（就像有人在这里实验中所做的那样）打开门避免重置比获得（可能的）微小的性能提升要危险得多。不能说我责怪他们。

---

客户端是否发送exec sp_reset_connection，等待响应，然后发送真正的sql？

编辑：我错了 - 请参阅此处 - 答案是否定的。

摘要：TDS 消息中设置了一个特殊位，指定应重置连接，SQL Server 会自动执行 sp_reset_connection。它在 Profiler 中显示为单独的批处理，并且始终在您要执行的实际查询之前执行，因此我的测试无效。

<罢工>
是的，它是单独批量发送的。

我编写了一个小 C# 测试程序来演示这一点，因为我很好奇：

using System.Data.SqlClient;

(...)

private void Form1_Load(object sender, EventArgs e)
{
    SqlConnectionStringBuilder csb = new SqlConnectionStringBuilder();
    csb.DataSource = @"MyInstanceName";
    csb.IntegratedSecurity = true;
    csb.InitialCatalog = "master";
    csb.ApplicationName = "blarg";

    for (int i = 0; i < 2; i++)
        _RunQuery(csb);
}

private void _RunQuery(SqlConnectionStringBuilder csb)
{
    using (SqlConnection conn = new SqlConnection(csb.ToString()))
    {
        conn.Open();

        SqlCommand cmd = new SqlCommand("WAITFOR DELAY '00:00:05'", conn);

        cmd.ExecuteNonQuery();
    }
}

启动 Profiler 并将其附加到您选择的实例，过滤我提供的虚拟应用程序名称。然后，在 cmd.ExecuteNonQuery(); 行上放置一个断点并运行该程序。

第一次跨步时，仅运行查询，等待 5 秒后您得到的只是 SQL:BatchCompleted 事件。当断点第二次到达时，您在分析器中看到的仍然只是一个事件。当您再次跨过去时，您立即会看到 exec sp_reset_connection 事件，然后在延迟后显示 SQL:BatchCompleted 事件。

摆脱 exec sp_reset_connection 调用（这对您来说可能是也可能不是合法的性能问题）的唯一方法是关闭 .NET 的连接池。如果您打算这样做，您可能需要构建自己的连接池机制，因为仅将其关闭而不执行其他操作可能会比承受额外往返的影响更大，并且您将拥有手动处理正确性问题。

Answer 2

此问答可能会有所帮助：
Sql Server Profiler 中的“exec sp_reset_connection”是什么意思？

不过，我使用 Entity Framework 和 MS-SQL 2008 R2 进行了快速测试。它表明“exec sp_reset_connection”在第一次调用后并不耗时：

for (int i = 0; i < n; i++)
{
    using (ObjectContext context = new myEF())
    {
                
        DateTime timeStartOpenConnection = DateTime.Now;
        context.Connection.Open();
        Console.WriteLine();
        Console.WriteLine("Opening connection time waste: {0} ticks.", (DateTime.Now - timeStartOpenConnection).Ticks);

        ObjectSet<myEntity> query = context.CreateObjectSet<myEntity>();
        DateTime timeStart = DateTime.Now;
        myEntity e = query.OrderByDescending(x => x.EventDate).Skip(i).Take(1).SingleOrDefault<myEntity>();
        Console.Write("{0}. Created By {1} on {2}... ", e.ID, e.CreatedBy, e.EventDate);
        Console.WriteLine("({0} ticks).", (DateTime.Now - timeStart).Ticks);

        DateTime timeStartCloseConnection = DateTime.Now;
        context.Connection.Close();
        context.Connection.Dispose();
        Console.WriteLine("Closing connection time waste: {0} ticks.", (DateTime.Now - timeStartCloseConnection).Ticks);
        Console.WriteLine();
    }
}

输出是这样的：

打开连接时间浪费：5390101个刻度。
585. 由 sa 创建于 12/20/2011 2:18:23 PM...（2560183 个刻度）。
关闭连接时间浪费：0ticks。

打开连接时间浪费：0 滴答。
584. 由 sa 创建于 12/20/2011 2:18:20 PM...（1730173 个刻度）。
关闭连接时间浪费：0ticks。

打开连接时间浪费：0 滴答。
583. 由 sa 创建于 12/20/2011 2:18:17 PM...（710071 个刻度）。
关闭连接时间浪费：0ticks。

打开连接时间浪费：0 滴答。
582. 由 sa 创建于 12/20/2011 2:18:14 PM...（720072 个刻度）。
关闭连接时间浪费：0ticks。

打开连接时间浪费：0 滴答。
581. 由 sa 创建于 12/20/2011 2:18:09 PM...（740074 个刻度）。
关闭连接时间浪费：0ticks。

所以，最后的结论是：不用担心“exec sp_reset_connection”！它没有浪费任何东西。

Answer 3

就我个人而言，我会离开它。

鉴于它的作用，我想确保范围内没有临时表或未打开的事务。

公平地说，如果不对生产数据库运行探查器，您将获得更大的性能提升。您是否有任何关于您可以从中获得什么的数字、文章或建议？

Answer 4

只需保持连接打开，而不是将其返回到池中，并在该连接上执行所有命令。