.net - 批量操作后 DbContext 非常缓慢

Question

似乎 EntityFramework 中的 DbContext 越来越慢，您在其上执行的操作（添加、删除、修改、查询）越多。几次操作后定期调用 SaveChanges() 不会解决该问题。唯一的解决方法是释放上下文并重新生成它。

向您传达一个想法：使用一个 DbContext 的过程大约需要 4 小时，而带有变通方法的代码只需要大约 45 分钟，所以这真的很重要！是否有我不知道的原因或开关？

Answer 1

这是EF5 性能注意事项的有用链接。

您是否使用更改跟踪代理？如果没有，您也许可以加快速度。从链接：

当 POCO 实体没有更改跟踪代理时，通过将实体的内容与先前保存的状态的副本进行比较来找到更改。当您的上下文中有许多实体时，或者当您的实体具有大量属性时，这种深度比较将成为一个漫长的过程，即使自上次比较以来它们都没有改变。

否则，您可以DbContextConfiguration.AutoDetectChangesEnabled = false按照评论和链接中的建议进行设置。DetectChanges()在完成一些通常会自动调用它的密集 DbSet/DbContext 方法调用后，您仍然可以显式调用。

您还可以减少上下文中的实体数量吗？如果您有一些不需要由 ObjectStateManager 跟踪的实体，也许可以使用 AsNoTracking() 查询。

Answer 2

似乎 EntityFramework 中的 DbContext 越来越慢，您在其上执行的操作（添加、删除、修改、查询）越多。

绝对可以 - 您的 DbContext（以及它所基于的 ObjectContext）保存了它曾经接触、加载、更新、保存的每个实体。

MSDN 博客文章的快速摘录：

您使用 ObjectContext 的次数越多，它通常就越大。这是因为它包含对它所知道的所有实体的引用，基本上是您查询、添加或附加的任何内容。所以你应该重新考虑无限期地共享同一个 ObjectContext。

由于您说该过程大约需要 4 个小时，我假设您有数千个正在修改的实体。Save Changes 不会转储对象图，您只是在创建越来越多的对象以供跟踪。每次进行更改时，都必须遍历图形，因此图形越大，所需的时间就越长。

您的解决方法真的是糟糕的代码吗？是否有一种方法可以拆分您的流程，以便每个部分创建和处理它自己的 DbContext 而不是共享一个？