实体框架mergeoption表示不良 [英] Entity Framework mergeoption notracking bad performance

问题描述

我有一个奇怪的行为，试图执行一个声明ObjectQuery MergeOption到NoTracking的查询，在这种情况下，实体框架不应该附加任何实体，而不是创建相对的ObjectStateEntry来跟踪实体状态。

I have a strange behavior trying to execute a query declaring ObjectQuery MergeOption to "NoTracking", in this case entity framework should not attach any entity and not create the relative ObjectStateEntry to track entity state.

问题是，而不是增加性能，它变得更糟，同样的查询需要10秒，默认的mergeoption（即AppendOnly），如果我尝试指定notracking

The problem is that instead of increase performance it get worse, the same query takes like 10 seconds with default mergeoption (that is AppendingOnly) and more the 1 minutes if I try to specify notracking

有人有解释吗？

推荐答案

如果您禁用变更追踪设置 NoTracking 合并选项可以节省将对象附加到上下文的性能成本，但另一方面您也会失去身份管理。

If you disable change tracking by setting the NoTracking merge option you save the performance costs of attaching objects to the contexts but on the other hand you also lose identity management.

这意味着可能会有更多的对象（许多具有相同的键）被实现。

This means that potentially much more objects - many with the same key - will be materialized.

示例：假设您有一个用户实体，具有角色集合作为导航属性。还假设您在数据库中有100万用户，并且所有用户都具有相同的10个角色，即每个用户都具有10个元素的角色集合。如果您运行以下查询...

Example: Suppose you have a User entity with a Roles collection as navigation property. Also suppose you have 1 million users in the database and all users are in the same 10 roles, i.e. every user has a roles collection with 10 elements. If you run the following query...

var users = context.Users.Include("Roles").ToList();

...实例化和实例化对象的数量取决于合并选项：

...the number of materialized and instantiated objects depends on the merge option:

• 如果您不使用 NoTracking ，则内存中将有1.000.010个对象，即100万用户，但只有10个角色，因为身份映射将确保每个密钥只有1个角色实现并附加到上下文中。对于所有用户的角色集合使用相同的10个角色实例。

• If you don't use NoTracking you will have 1.000.010 objects in memory, namely 1 million users, but only 10 roles because identity mapping will ensure that only 1 role per key is materialized and attached to the context. The same 10 role instances are used for all user's Roles collection.

如果您使用 NoTracking 但是，EF不会将对象附加到上下文，因此身份管理被禁用，内存中将有11.000.000个对象：每个用户100万个用户和10个角色实例，即1000万个角色对象。所以，当物体被附加到上下文的时候，你的物化对象就是物体的十倍以上。

If you use NoTracking however, EF won't attach objects to the context, hence identity management is disabled and you will have 11.000.000 objects in memory: 1 million users and 10 role instances per user, i.e. 10 million role objects. So, you have more than 10 times as many materialized objects as when the objects are attached to the context.

对象实质化分类为中等性能成本：

操作：实现对象


相对成本：中等


频率：查询返回的每个对象一次。




注释：
读取返回的DbDataReader对象并创建
对象的过程，并设置基于
中每个实例的DbDataRecord中的值的属性值类。 如果ObjectContext中的对象已经存在
，并且该查询使用 AppendOnly 或
PreserveChanges 合并选项，则此阶段不会影响性能。

Operation: Materializing the objects
Relative Cost: Moderate
Frequency: Once for each object that a query returns.

Comments: The process of reading the returned DbDataReader object and creating objects and setting property values that are based on the values in each instance of the DbDataRecord class. If the object already exists in the ObjectContext and the query uses the AppendOnly or PreserveChanges merge options, this stage does not affect performance.

换句话说：如果查询使用 NoTracking merge选项，这个阶段确实会影响性能，可能的是，禁用变更跟踪的性能优势被残疾人身份管理和倍增对象实现的缺点所破坏。

In other words: If the query uses the NoTracking merge option, this stage does affect performance and it might be possible that the performance benefits of disabled change tracking are destroyed by the drawbacks of disabled identity management and multiplied object materialization.

这篇关于实体框架mergeoption表示不良的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！