EF Core 6：通过分析器检查令人震惊答案

【问题标题】：EF Core 6 : inspection through profiler is shockingEF Core 6：通过分析器检查令人震惊
【发布时间】：2022-01-03 04:25:24
【问题描述】：

我已经通过 SQL Server Profiler 检查了 EF Core 6，从性能的角度来看，这令人震惊。

这里没有什么很好的介绍：

var user = App.Ctx.LoginUsers;

这段代码没有配置，也很好：

user = App.Ctx.LoginUsers;

这里，分析的代码也不错：

var users = App.Ctx.LoginUsers.ToList();

但是使用此代码，在分析时非常糟糕，因为它已经在上面的上下文内存中：

users = App.Ctx.LoginUsers.ToList();

如果每个查询都从 SQL Server 进行四舍五入，即使它在上下文内存中，那么性能将会是灾难吗？

但我们预计仅针对已更改的差异数据往返 SQL 服务器

插入以添加到 dbcontext 内存中
仅修改为在 dbcontext 内存中更新
只有从 dbcontext 内存中删除才能删除

并从 dbcontext 内存中提供任何询问数据。

通过这种方式，我们认为性能会大幅提升。

【问题讨论】：

标签： sql-server entity-framework-core linq-to-sql c#-6.0 sql-server-profiler

【解决方案1】：

如果每个查询都是从 sql server 进行四舍五入

是的，这就是查询的作用。他们从数据库中获取数据。如果您想访问之前查询中加载的数据，请使用DbSet< TEntity >.Local，或将它们存储在您自己的集合中。

DbContext Change Tracker 存储从您的数据库中检索到的实体，但它并非设计为通读缓存。如果您运行另一个查询，另一个查询将被发送到数据库。

【讨论】：

【解决方案2】：

“灾难”是什么意思？

默认情况下，EF 将跟踪它已经获取的引用。不要将此与缓存混淆，因为这是出于性能原因。将整组实体加载为跟踪引用不是一个好主意。不是因为尽管已经跟踪了这些实例，但它仍然意味着对数据库的额外往返，而是因为 EF DbContext 跟踪的实例越多，使用的内存就越多，获取额外数据所需的时间就越长，因为这些操作将自动将任何已跟踪的实例与返回的数据的任何关系关联起来。

如果您获取大量数据并且不需要 DbContext 跟踪该数据（即您不打算更新它，因此不需要更改跟踪），请使用 AsNoTracking()。

var users = App.Ctx.LoginUsers.AsNoTracking().ToList();

这仍会从数据库中获取所有用户，但上下文不会跟踪这些实例。

如果您知道您已经加载了所需的数据，或者想要在转到数据库之前检查并使用任何预加载和跟踪的实例，则使用 DbSet 中的 Local 集来告诉 EF 只需转到跟踪实例：

// Look for a tracked instance:
var user = App.Ctx.LoginUsers.Local.SingleOrDefault(x => x.UserId == userId);
if (user == null)
   user = App.Ctx.LoginUsers.Single(x => x.UserId == userId);

当您知道某些数据可能已经被跟踪并且您正在处理分离的实体时，这是一种常见的策略。（即加载了AsNoTracking 或反序列化的用户）Local 调用检查该实体的跟踪存储，因此无需往返数据库，然后如果我们找不到它，我们可以从数据库加载和跟踪它.

另一个需要注意的细节是，虽然针对 DbContext 的查询会返回已跟踪的实例仍会触发 SQL 查询，但跟踪的实例不会由该查询返回的数据更新.例如，如果您将用户加载到 DbContext 中，那么不使用该 DbContext 实例的其他一些进程会去修改数据库中的一个或多个用户，从 DbContext 中获取这些用户将返回跟踪数据，因为它是加载。将对数据库运行 SQL 查询，但是任何修改的数据状态不会自动更新任何已跟踪的实体。

【讨论】：