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

Question

上下文：

我正在从Access迁移到SQL Server。这是一个复杂的迁移过程，并且经常运行-因此，我将其集成到了网站中，以便用户在需要时可以偶尔自己做。

怪异：

因此，我最初决定在每个区域的末尾使用一个上下文进行常规的SaveChanges()。

插入大约60k时，保存时间非常长。

好吧，我想，我将在每次输入后运行SaveChanges。花了很长时间。太长了。

好的，所以我决定尝试SaveChangesAsync，但是根本无法正常工作。我愿意给这个区域一个属于自己的Dbcontext，只是让它保存在后台，在结局之前我会等待它。无法解决这个问题。最初它会引发错误，然后根本就不会保存数据。

好吧，所以下一步就是尝试给此方法自己的DbContext。像梦一样工作。

然后，我给每种方法（总共约13种）分配了自己的DbContext。一切都很快。

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

运行SaveChanges()之后是否还有可以清理的东西？还是我应该简单地使用许多DbContext？我只是试图避免每次都打开一个新的连接以节省一点时间，但这并不是什么大问题，但是我仍然缺乏理解为什么的情况。有人可以教育我吗？

Answer 1

运行SaveChanges（）之后是否还有可以清理的东西？

是的。变更跟踪器。默认情况下，DbContext将保留所有已加载的实体，在这种情况下，这使得加载其他实体和识别更改的实体的开销都越来越大。

因此，请使用多个DbContext实例，或在SaveChanges（）之后分离所有实体，如此处的答案How do I clear tracked entities in entity framework;