.NET Core 3.1 EF中DbContext批量添加3000条数据过慢求助

核心原因 #

你遇到的循环越往后越慢的问题，本质是EF变更追踪器的累积开销导致的：每次调用Add或AddAsync时，DbContext都会将实体加入变更追踪器维护。随着实体数量从0增加到3000，变更追踪器需要管理的对象、关系和状态越来越多，内存占用持续上升，后续的实体添加操作会因为追踪器的内部处理逻辑（如状态检测、快照对比）变得越来越耗时。

针对批量添加的优化方案 #

因为你必须保留变更追踪，所以不能直接禁用追踪，以下是可行的优化手段：

1. 分批处理+批量添加

将3000个实体拆分成小批次（比如500个一批），每批用AddRange/AddRangeAsync批量添加，调用SaveChangesAsync后，手动分离已保存的实体，避免追踪器持续累积：

示例代码（修改业务层调用逻辑）：

int batchSize = 500;
for (int i = 0; i < itemsToSave.Count; i += batchSize)
{
    var batch = itemsToSave.Skip(i).Take(batchSize).ToList();
    // 调用仓储的批量添加方法（需要新增）
    await _myRepository.CreateRangeAsync(batch, true);
    // 分离已保存的实体，释放追踪资源
    foreach (var entity in batch)
    {
        _myRepository.DbContext.Entry(entity).State = EntityState.Detached;
    }
}

对应的仓储层新增批量方法：

public async Task CreateRangeAsync(IEnumerable<TEntity> entities, bool isSaved = true)
{
    await DbContext.Set<TEntity>().AddRangeAsync(entities);
    if (isSaved)
    {
        await SaveChangesAsync();
    }
}

2. 优化变更追踪器性能

在批量添加期间，关闭一些非必要的追踪功能，减少开销：

// 在批量操作前临时关闭自动变更检测
DbContext.ChangeTracker.AutoDetectChangesEnabled = false;

// 执行批量添加和保存
await DbContext.Set<TEntity>().AddRangeAsync(itemsToSave);
await DbContext.SaveChangesAsync();

// 恢复自动变更检测（如果后续需要）
DbContext.ChangeTracker.AutoDetectChangesEnabled = true;

如果不需要实体验证，也可以关闭验证：

DbContext.ValidateOnSaveEnabled = false;

关于AddRangeAsync无数据保存的排查方向 #

你提到用AddRangeAsync后无数据也无报错，大概率是以下原因：

• 未正确等待异步操作：确保调用AddRangeAsync时加了await，否则实体还没被添加到DbContext就调用SaveChangesAsync，自然不会有数据写入；
• 实体验证失败：EF默认在SaveChanges时执行实体验证，若验证不通过会静默失败（除非你捕获了异常）。可以手动调用以下代码查看验证错误：

  var validationErrors = DbContext.GetValidationErrors();
  foreach (var error in validationErrors)
  {
      // 输出错误信息
  }
  

• 数据库层面问题：比如主键冲突、外键约束不满足，但EF未抛出异常。可以开启EF的SQL日志，查看执行的SQL语句和数据库返回的错误。

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