我在某处读到你不应该在Entity Framework或SQL上使用PLINQ。我不记得我在哪里阅读或原因是什么，但我做了一些实验。使用传统的LINQ to Entity Framework来加载预计会变得非常大的数据库表，目前需要12到13毫秒。但是，当我添加.AsParallel（）时，相同的查询在2到4毫秒内运行，我得到了相同的结果。
因此，如果我使用PLINQ更快地获得相同的结果，那么将PLINQ用于实体框架会有什么陷阱？
答案 0 :(得分：1)
存在一些危险，IE无法同时访问多个线程的DbContext。而且往往很少有好处，即PLINQ会同步访问IEnumerable.MoveNext（），它可以完成读取数据，创建实体以及与更改跟踪器交互的所有工作。
但是如果你对返回的实体做了很多工作，那就不会触及DbContext（即没有SaveChanges（），没有延迟加载等），你可以使用PLINQ。
但是我能想到的大部分示例都可以通过将操作构建到原始查询中，或者通过执行服务器端原始SQL来更好地进行优化。
因此，如果你有一堆CPU密集型域逻辑需要在一组实体中运行，你可以并行地对结果进行操作，但你最好在内部创建一个单独的DbContext < / em>并行执行块。