如果我使用其中的许多而不是一个，EFCore DbContext 会更快吗？ 为什么？

Question

语境：

我正在从 Access 迁移到 SQL 服务器。 这是一个复杂的迁移并且运行得相当频繁——所以我将它集成到网站中，这样用户可以在需要时偶尔自己进行。

怪异：

所以我最初决定 go 与一个上下文在每个区域的末尾执行常规SaveChanges() 。

当它达到 ~ 60k 插入时，需要很长时间才能保存。

好的，我想，我会在每次输入后运行SaveChanges 。 花了很长时间。 长得离谱。

好的，所以我决定尝试SaveChangesAsync并且根本无法让它工作。 我愿意为这个区域提供它自己的Dbcontext并让它保存在后台，在结局之前我会等待它。 无法让它发挥作用。 最初它会抛出一个错误，然后它根本不会保存数据。

好的，所以下一步是尝试为这个方法提供自己的DbContext 。 像梦想一样工作。

然后我给了每个方法（总共大约 13 个）他们自己的DbContext 。 一切都非常快。

所以我的问题是：一个DbContext有 13 个SaveChanges()调用和 13 个DbContexts有 13 个SaveChanges() () 调用有什么区别？

运行SaveChanges()后是否有一些我可以清理的东西？ 还是我应该只是 go 与许多DbContext的？ 我只是想避免每次都打开一个新的连接来节省那一点时间，但这并不是什么大问题，但我仍然不明白为什么会这样。 有人可以教育我吗？

Answer 1

运行 SaveChanges() 后是否有一些我可以清理的东西？

是的。 更改跟踪器。 默认情况下，DbContext 将保留所有加载的实体，在这种情况下，加载额外的实体和识别更改的实体会变得越来越昂贵。

所以使用多个 DbContext 实例，或者在 SaveChanges() 之后分离所有实体，如这里的答案How do I clear tracked entities in entity framework ;