批量操作后，DbContext令人痛苦地缓慢

Question

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

向您传达一个想法：一个使用一个DbContext的过程需要大约4个小时，而带有变通方法的代码只需要大约45分钟，所以它非常重要！有没有我不知道的理由或转变？

Answer 1

这是performance considerations for EF5的有用链接。

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

  

当POCO实体没有更改跟踪代理时，更改为   通过比较您的实体的内容与a的副本找到   以前保存的州。这种深刻的比较将变得漫长   当您在上下文中有许多实体时，或当您的实体中有多个实体时   实体具有非常大量的属性，即使它们都不是   自上次比较以来发生了变化。

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

您是否还可以减少上下文中的实体数量？如果你有一些不需要被ObjectStateManager跟踪的实体，也许可以使用AsNoTracking（）查询。

Answer 2

  

似乎EntityFramework中的DbContext不断获取   执行越多的操作（添加，删除，修改，查询）越慢   在它上面。

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

快速摘自MSDN blog post：

  

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

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

你的解决方案是非常糟糕的代码吗？有没有办法分割你的流程，以便每个部分创建，并处理它自己的DbContext而不是共享一个？