在C＃和Entity Framework 3.5中，我有一个包含数百万条记录的上下文。这需要大约2 GB的RAM。一旦我打电话给SaveChanges()，它就会开始填满我的8 GM RAM并开始交换。
我使用了一个分析器，结果发现它是占用内存的SQL查询。
现在我想分批保存，但我遇到了问题。
我有一个Locations的集合（后者又有东西的集合和子集）。当我分批分割并为每个分配新的上下文时，只要我context.AddToOrder(firstBatch)，所有批次中的所有位置突然有实体状态{{ 1}}，即使他们没有Added。这使得保存失败，因为Order关系不存在。
为什么当我只将一部分对象添加到上下文中时，原始集合中的所有对象都会获得状态Order -> Location？
答案 0 :(得分：2)
我有一个包含数百万条记录的上下文。这需要大约2 GB的RAM。
我知道你不会喜欢这个答案，但很简单。 不要这样做。 EF，特别是EFv1还没有为此做好准备。 EF不是处理数十MB的工具。您必须使用其他工具来处理大型数据集，或者将更新分成多个（在您的情况下为数千甚至数百万）小变更集，每个变更集都使用自己的上下文。
我想当你打电话给SaveChanges时，EF会尽力发挥其魔力，包括检测实体的变化并准备要执行的语句。可能存在内存泄漏但由于GC可能还会有大量未释放的内存。在这种情况下，与您当前的问题无关。
顺便说一下。 EF将尝试将您的修改存储在单个事务中。因此，如果您尝试在单个事务中保存2GB，则可能会出现更多级别的问题。