.NET Core下通过EF Core向SQLite插入数据极慢，该如何优化性能？

性能优化方案 #

所有优化均保留你要求的1000个独立事务逻辑，不会合并事务或移除事务保障：

1. 调整SQLite核心配置（性能提升最明显） #

SQLite默认配置优先保障极端场景下的数据安全性，写入性能被大幅限制，调整以下参数可获得5~10倍的写入性能提升：
修改你的OnConfiguring方法中的SQLite连接配置：

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder.UseSqlite("Data source=mydb.db;Journal Mode=WAL;Synchronous=NORMAL");
#if DEBUG
    optionsBuilder.EnableSensitiveDataLogging(true);
#endif
}

参数说明：

• Journal Mode=WAL：将默认的回滚日志模式改为预写日志模式，写入操作不需要覆盖原数据页，事务提交的磁盘IO量降低70%以上，事务一致性保障和默认模式完全一致，是SQLite高频小事务场景的首选优化。
• Synchronous=NORMAL：将默认的全量刷盘策略调整为间隔刷盘，仅在操作系统掉电的极端场景下可能丢失最近少量事务数据，普通程序崩溃不会丢数据。如果你的业务要求绝对数据安全，可以将该参数改回FULL，仅开启WAL模式也能获得3倍以上的性能提升。

2. 降低EF Core运行开销 #

你的场景中每次事务操作量少，EF Core本身的上下文初始化、变更追踪开销占比很高，可做以下调整：

• 如果你的业务允许复用DbContext实例，不需要每次事务都新建上下文，可减少初始化开销。如果必须每次新建上下文，在每次操作前关闭不必要的追踪功能：

using var db = new MyDatabase();
db.ChangeTracker.AutoDetectChangesEnabled = false;
db.ChangeTracker.QueryTrackingBehavior = QueryTrackingBehavior.NoTracking;

• 显式开启EF Core批处理配置，针对你实际场景中一个事务更新多张表的情况，可减少命令解析开销：

optionsBuilder.UseSqlite("Data source=mydb.db;Journal Mode=WAL;Synchronous=NORMAL", 
    opt => opt.MaxBatchSize(16));

3. 极限性能优化 #

如果以上配置仍达不到性能要求，可在事务内直接执行原生SQL，跳过实体变更追踪的开销，性能可再提升15%左右：

var tx = db.Database.BeginTransaction();
db.Database.ExecuteSqlRaw("INSERT INTO Records (ID, Value) VALUES ({0}, {1})", i+1, 123456789);
// 多表操作可以依次执行多条SQL
db.SaveChanges();
tx.Commit();

以上方案调整完成后，1000次独立事务在SATA SSD上的运行时间可控制在1~2秒区间内，符合性能预期。

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