ASP.NET Core中DbContext实例疑似共享资源/合并查询问题求助

代码层面的核心问题修复 #

你的代码中直接操作DbContext底层连接时，存在连接管理和Command创建的不规范，这是导致异常表现的主要原因：

1. 不必要的手动连接打开
   你手动调用了OpenConnectionAsync，但EF Core会在执行命令时自动管理连接的打开与关闭。手动打开后未显式关闭，会导致连接在DbContext生命周期内保持打开状态，连接池复用该物理连接时，会话时长会被累计——这就是你在sp_whoisactive中看到超长时长的原因：该时长是连接会话的总时长，而非当前查询的执行时间。

2. 错误的Command创建方式
   使用context.Database.GetDbConnection().CreateCommand()创建的Command不会自动关联DbContext的事务和连接上下文，应该改用EF Core提供的context.Database.CreateCommand()方法，它会自动处理这些关联逻辑。

修复后的代码如下：

public async Task<DataTable> GetDataTableFromSqlServerByQuery(string sql)
{
    var dt = new DataTable();
    
    using (var cmd = context.Database.CreateCommand())
    {
        cmd.CommandText = sql;
        // 无需手动打开连接，ExecuteReaderAsync会自动处理连接的打开与关闭
        using (var reader = await cmd.ExecuteReaderAsync())
        {
            dt.Load(reader);
        }
    }

    return dt;
}

其他排查方向 #

1. 检查Singleton服务是否意外持有DbContext #

尽管你已验证DbContext是Scoped注册，但如果存在Singleton生命周期的服务依赖注入了Scoped的DbContext，会导致该DbContext被所有请求共享（ASP.NET Core默认会阻止这种跨生命周期依赖，但如果通过IServiceProvider.GetService等手动方式获取，可能绕过检查）。

排查所有Singleton服务的构造函数，确保没有直接或间接注入Scoped的DbContext。

2. 确认异步操作中无线程共享DbContext #

检查代码中是否存在将DbContext实例传递给其他线程、或在异步回调中复用DbContext的情况。DbContext不是线程安全的，即使是Scoped实例，跨线程访问也会导致状态混乱。

3. 重新理解sp_whoisactive的时长字段 #

sp_whoisactive中的duration列显示的是数据库会话的总时长，而非单个查询的执行时间。当连接池复用物理连接时，会话时长会从连接创建时开始累计，这并非查询合并的表现，而是连接池正常工作的结果。你可以查看start_time列确认当前查询的实际启动时间，区分会话时长与查询时长。

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