为何SSMS连接后C#控制台应用ExecuteReader性能大幅提升？

这是个非常有意思的观察，我来帮你拆解几个最可能的原因：

1. 连接建立的开销差异（核心原因） #

你提到的ExecuteReader计时应该包含了从连接建立到获取结果的完整流程，而不仅仅是存储过程的执行时间。当没有SSMS连接时，每次启动控制台应用都需要：

• 完成TCP三次握手建立新连接
• 执行SQL Server登录认证
• 初始化会话上下文（分配内存、设置默认选项等）
  这些步骤加起来大概占了200ms（300ms总耗时 - 存储过程100ms执行时间）。

当SSMS保持连接时，SQL Server的连接管理组件处于活跃状态：

• 服务器端的TCP连接队列已经预热，新连接的建立速度更快
• 会话资源（比如内存池、工作线程）已经被提前分配，避免了首次初始化的开销
  控制台第二次运行时，连接建立的耗时大幅降低，所以ExecuteReader的总耗时就从300ms降到了10ms（几乎只包含存储过程执行+结果返回的时间）。

关闭SSMS后，服务器端的活跃连接消失，这些预热的资源会被逐步回收，所以再次运行控制台时又回到了初始的300ms耗时。

2. 执行计划缓存？不，不是这个 #

你提到存储过程自身的计时始终是100ms，说明存储过程的执行计划已经在首次运行时被缓存了（SQL Server会自动缓存存储过程的执行计划），所以这个现象和执行计划缓存无关——毕竟没有SSMS时多次运行控制台的耗时也是稳定的300ms，说明执行计划早就被缓存了。

3. 连接属性的隐性影响？ #

虽然你说sys.dm_exec_connections显示连接无差异，但SSMS的默认连接属性（比如SET ARITHABORT ON、SET QUOTED_IDENTIFIER ON）可能和控制台应用的连接属性一致，但SSMS的连接会提前触发一些服务器端的初始化操作（比如加载系统元数据缓存），这些缓存可以被后续的控制台连接复用，减少了会话初始化时的元数据查询开销。不过这个影响通常比连接建立的开销小很多。

验证方法 #

你可以在控制台应用中单独计时连接建立阶段和ExecuteReader阶段，来明确开销的来源：

var stopwatch = Stopwatch.StartNew();
using (var conn = new SqlConnection(connectionString))
{
    conn.Open();
    stopwatch.Stop();
    Console.WriteLine($"连接建立耗时：{stopwatch.ElapsedMilliseconds}ms");

    stopwatch.Restart();
    using (var cmd = new SqlCommand("YourStoredProcedure", conn))
    {
        cmd.CommandType = CommandType.StoredProcedure;
        using (var reader = cmd.ExecuteReader())
        {
            // 读取结果逻辑
        }
    }
    stopwatch.Stop();
    Console.WriteLine($"ExecuteReader耗时：{stopwatch.ElapsedMilliseconds}ms");
}

内容的提问来源于stack exchange，提问作者user2849221