使用EF Core将1.3GB比特币交易CSV导入SQLite的提速方法咨询

基础配置优化 #

• 关闭变更跟踪：导入场景下不需要EF的实体状态跟踪能力，导入前将 DbContext.ChangeTracker.AutoDetectChangesEnabled = false，相关查询逻辑附加 AsNoTracking() 配置，直接跳过实体快照生成、变更比对的开销。
• 禁用保存验证：提前完成CSV数据合法性校验后，关闭EF默认的实体验证逻辑：DbContext.ChangeTracker.ValidateOnSaveEnabled = false，省去每批次提交前的全量实体属性校验耗时。
• 数据库层面临时调优：针对不同数据库适配导入临时参数，以SQLite为例，导入前执行 PRAGMA synchronous = OFF; PRAGMA journal_mode = WAL; 关闭磁盘同步校验、开启预写日志，可大幅提升写入速度，导入完成后再恢复原有配置即可，不影响EF多数据库适配能力。

批处理逻辑优化 #

• 调整批次大小：原有10万的单批大小过大，会导致上下文内存占用过高、GC频繁，建议将单批大小调整到1000~5000区间，同时在上下文配置时指定对应数据库的最大批处理大小，例如SQLite下配置：

  optionsBuilder.UseSqlite("你的连接字符串", b => b.MaxBatchSize(1000));
  

  让EF可以将单批多条插入合并为少量SQL语句执行，减少数据库交互次数。
• 每批重建上下文：不要复用同一个DbContext处理所有批次，每完成一个批次的写入就释放当前上下文，新建上下文处理下一批，避免变更跟踪器累积大量无用实体，导致后续SaveChanges遍历开销指数级上升。
• 使用AddRange批量追加实体：单批次实体读完后统一调用 DbContext.AddRange(实体列表) 追加，不要循环调用Add方法，可省去每次调用Add触发的内部检查开销。

读取环节优化 #

• CsvHelper流式读取：不要全量加载CSV到内存，直接用CsvHelper的GetRecords<T>()方法流式迭代读取，每攒够指定批次大小就提交写入，减少内存占用和GC耗时。
• 关闭CsvHelper冗余校验：提前确认CSV格式、字段类型匹配的前提下，关闭CsvHelper的读取异常抛出、类型自动校验逻辑，减少读取环节的额外开销。

版本升级优化 #

• 升级到EF Core 7+版本：EF Core 7开始原生优化了批量插入、更新的执行逻辑，批量写入性能相比EF Core 6及更早版本提升2~3倍，无需引入第三方扩展即可获得接近原生导入的性能表现。

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