Access迁SQL Server时，多EF Core DbContext比单个更快？原因何在？

这是个非常典型的EF性能坑，我在做数据迁移和批量导入时也踩过一模一样的雷，咱们来把问题拆解开说清楚：

1. 单个DbContext多次SaveChanges vs 多个DbContext各一次的核心区别 #

核心问题出在**EF的ChangeTracker（变更跟踪器）**上：

• 单个DbContext会持续跟踪所有你创建、查询过的实体，哪怕你调用了SaveChanges()提交了变更，这些实体依然会留在ChangeTracker里，状态会从Added/Modified变为Unchanged。
• 当你累计处理到60k条数据时，ChangeTracker里已经缓存了数万条实体，每次调用SaveChanges()时，EF需要遍历所有跟踪的实体，检查它们的状态变化——哪怕你这次只新增了100条，它也要扫完所有几万条才能确定哪些需要提交，这就是耗时爆炸的原因。
• 而每个方法用独立DbContext的话，每个DbContext只跟踪当前方法里创建的少量实体，SaveChanges()只需要处理这些少量实体，自然速度飞快。而且方法结束后DbContext被释放，ChangeTracker里的所有实体也会被回收，不会累积负担。

2. SaveChanges()后需要清理的内容吗？ #

是的，如果你要复用单个DbContext处理多批数据，必须手动清理ChangeTracker：

• 调用context.ChangeTracker.Clear()可以清空所有被跟踪的实体，避免内存占用越来越大，同时让后续的SaveChanges()不用再扫描之前的实体。
• 但即使调用了Clear，DbContext内部还有一些元数据缓存、状态标记，长期复用还是可能出现一些微妙的状态问题（比如你遇到的时而报错、时而存不上数据），不如直接创建新的DbContext彻底。

3. 是否应该直接使用多个DbContext？ #

分场景来看：

• 对于批量迁移/导入这类独立的高数据量操作：非常推荐用多个独立DbContext。每个操作都是原子性的，不需要共享实体状态，而且能彻底避免ChangeTracker的性能瓶颈。
• 对于常规业务操作（比如同一个请求里修改关联实体）：单个DbContext更合适，因为它能保证事务一致性，还能自动跟踪实体之间的关联关系，避免出现数据不一致的问题。

另外你担心的“重复打开连接”其实不用太在意：EF会自动使用数据库连接池，创建新的DbContext时，会从连接池里获取空闲连接，而不是每次都建立新的物理连接，所以开销非常小，远小于ChangeTracker过载带来的性能损失。

补充：你之前遇到的SaveChangesAsync和后台保存失败的原因 #

大概率是因为DbContext不是线程安全的：如果你的后台保存是多线程操作同一个DbContext，就会导致ChangeTracker的状态混乱，出现报错、数据丢失的情况。而每个方法用独立DbContext的话，每个DbContext只在单线程里被使用，自然就不会有这些问题了。

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