C# ASP.NET EF并行多库连接取数的可行性与优化咨询

需要从数据库中获取18000条记录并转换为DTO，涉及的refIds是参考表的18000个唯一ID。当前使用的代码如下：

int batchSize = 1000;
var refBatchList = new List<List<int>>();

for (var i = 0; i < refIds.Count; i += batchSize)
{
    refBatchList.Add(refIds.Skip(i).Take(batchSize).ToList());
}


var dbDataRetrievalTasks = refBatchList.Select(async refIdsBatch => await GetReferencesAsync(refIdsBatch, new data.Entities()));
var results = await Task.WhenAll(dbDataRetrievalTasks);

上述代码创建多个并行执行的任务，调用以下异步方法从数据库获取数据：

private async Task<List<reference>> GetReferencesAsync(List<int> ids, JIVE.data.Entities db)
{
    var result = await db.Set<reference>()
        .Where(x => ids.Contains(x.reference_id))
        .AsNoTracking()
        .ToListAsync();
    return result;
}

用户问题：
由于采用并行方式发起数据库调用，会使用多个数据库连接，此场景下将产生18个不同的数据库连接（对应18个批次）。请问：

1. 这种取数方式是否可行？
2. 该方式存在哪些弊端？
3. 是否有更优的实现方案？

（注：用户已知晓若批次过多，Task.WhenAll()可能导致线程池受限，但当前场景最大批次为20）

一、这种取数方式是否可行？ #

可行，但属于「能用但不够优化」的实现。当批次数量控制在20以内时，线程池和数据库连接池通常能承受对应的压力，不会直接引发系统崩溃，但会带来额外的性能开销和潜在风险。

二、存在的弊端 #

• 数据库连接池压力激增：18个并行请求会瞬间占用18个连接池连接，若此时系统存在其他业务请求，极易导致连接池耗尽，后续请求被迫排队等待，拖慢整体系统响应速度。
• 数据库负载叠加：每个批次的WHERE IN查询都会产生独立的执行计划（部分数据库可能复用，但仍存在额外解析开销），并行查询会同时加大数据库的CPU、IO负载；若参考表数据量较大，多个IN查询并行执行还可能引发锁竞争或资源争抢，影响数据库整体性能。
• 资源浪费：每次调用GetReferencesAsync都新建data.Entities（DbContext）实例，虽然EF Core会自动管理连接，但频繁创建DbContext会带来不必要的对象初始化开销，且多个DbContext并行操作会增加内存占用。
• 线程池波动风险：即使20个批次不算多，异步任务的调度仍会占用线程池线程；若此时系统有CPU密集型任务运行，可能导致线程池线程被抢占，影响数据查询任务的执行效率。

三、更优实现方案 #

1. 增大批次规模，减少并行请求数 #

多数数据库（如SQL Server、MySQL）支持IN子句包含数千个参数，18000条ID直接单批次查询通常是可行的。这样仅需占用1个数据库连接，彻底避免并行带来的连接池和数据库负载问题，代码也会更简洁：

using var db = new JIVE.data.Entities();
var allReferences = await db.Set<reference>()
    .Where(x => refIds.Contains(x.reference_id))
    .AsNoTracking()
    .ToListAsync();

若数据库对IN子句参数数量有限制（比如Oracle默认限制1000个），可将批次调整为符合限制的最大值（如1000条/批），但改为串行执行而非并行，同样能减少连接池压力。

2. 规范DbContext的创建与释放 #

DbContext并非线程安全，不能在多个并行任务中共享；但也不应随意创建后不及时释放。建议在GetReferencesAsync内部用using包裹DbContext，确保资源及时回收：

private async Task<List<reference>> GetReferencesAsync(List<int> ids)
{
    using var db = new JIVE.data.Entities();
    return await db.Set<reference>()
        .Where(x => ids.Contains(x.reference_id))
        .AsNoTracking()
        .ToListAsync();
}

3. 限制并行度，避免资源耗尽 #

如果确实需要保留并行查询的方式，可通过SemaphoreSlim限制同时执行的任务数，避免瞬间占满连接池，比如限制为8个并行请求：

int batchSize = 1000;
var refBatchList = new List<List<int>>();
for (var i = 0; i < refIds.Count; i += batchSize)
{
    refBatchList.Add(refIds.Skip(i).Take(batchSize).ToList());
}

var semaphore = new SemaphoreSlim(8); // 限制最大并行数为8
var allResults = new List<List<reference>>();

foreach (var batch in refBatchList)
{
    await semaphore.WaitAsync();
    try
    {
        var batchResult = await GetReferencesAsync(batch);
        allResults.Add(batchResult);
    }
    finally
    {
        semaphore.Release();
    }
}

// 合并所有批次结果
var allReferences = allResults.SelectMany(r => r).ToList();

4. 预编译查询，减少数据库解析开销 #

对于重复执行的WHERE IN查询，可使用EF Core的预编译查询功能，提前生成执行计划，减少数据库的解析开销：

// 预编译查询（定义为静态字段，确保只编译一次）
private static readonly Func<JIVE.data.Entities, List<int>, Task<List<reference>>> _getReferencesQuery =
    EF.CompileAsyncQuery((JIVE.data.Entities db, List<int> ids) =>
        db.Set<reference>()
            .Where(x => ids.Contains(x.reference_id))
            .AsNoTracking()
            .ToList());

private async Task<List<reference>> GetReferencesAsync(List<int> ids)
{
    using var db = new JIVE.data.Entities();
    return await _getReferencesQuery(db, ids);
}

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