【性能优化】EFCore性能优化(二)-禁用实体跟踪

阅读本文你的收获

了解EF Core的实体跟踪机制及其对性能的损害
学习EF Core禁用跟踪机制的应用场景

在【性能优化】EFCore性能优化(一)中我分享了EF Core在使用上需要注意的地方，有：

IEnumerable和IQueryable两种接口要充分理解，区别使用。
EF默认自带实体跟踪机制，只读查询用非跟踪式查询可以提高效率。用AsNoTracking方法。
EF对批量操作的支持不太高效，所以像批量添加、删除、修改等操作的执行效率，要注意分析与改进。
对于一些复杂查询，EF帮我们生成的SQL语句有时是低效的，这时可以让EF直接执行原生SQL语句，或者改用ADO.NET方式去执行。

接着上一篇，本次继续分享EF的实体跟踪机制，及如何禁用跟踪机制。

一、EF Core的实体跟踪机制

EF Core的实体跟踪机制是一种在应用程序中跟踪由EF(实体框架)管理的实体对象的方式。它能够自动检测对实体对象的更改，并将这些更改同步到数据库中。

1.1 实体跟踪机制什么情况下生效？

实体跟踪机制在以下情况下生效：

当通过查询从数据库中检索实体对象时，实体框架会自动跟踪这些对象的状态。
当应用程序对实体对象进行更改时，实体框架会自动检测这些更改，当你调用SaveChanges方法时，EF Core会将这些更改应用到数据库中。

以下案例将创建一个方法来演示实体跟踪：

using(var context = new BlogContext())
{
    // 加载一个博客及其所有帖子（开始跟踪）
    var blog = context.Blogs
              .Include(b => b.Posts)  // 使用 Include 方法确保相关实体的加载，这会导致实体被 EF Core 开始跟踪。
              .FirstOrDefault(b => b.BlogId == 1);
    // 假设我们修改了某些属性值，例如博客的 URL 和帖子的标题。
    blog.Url = "http://example.com/new-url";
    blog.Posts[0].Title = "New Post Title"; // 修改了第一个帖子的标题。
    
    //当我们提交更改时，EF Core 会自动检测到这些更改并生成相应的 SQL 语句来更新数据库。这是因为我们在加载时开始跟踪了这些实体。
    context.SaveChanges(); // 这将提交所有更改到数据库。
}

1.2 实体对象的状态有哪些？

实体对象的状态有以下几种：

未更改（Unchanged）：实体对象与数据库中的相应记录完全匹配，没有进行任何更改。
已添加（Added）：实体对象是新创建的，并且尚未插入到数据库中。
已删除（Deleted）：已从数据库中删除相应记录的实体对象。
已修改（Modified）：实体对象有一个或多个属性的更改，但尚未同步到数据库中。
已分离（Detached）：实体对象已从数据库中分离，不再由实体框架跟踪。

以下是一个示例代码片段，演示如何通过实体对象状态添加新数据：

//新增博客
using (var context = new BlogContext())
{
    var blogToAdd = new Blog{ /* 属性设置 */ };
    context.Blogs.Add(blogToAdd ); // 将实体对象状态设置为附加
    context.Entry(blogToAdd ).State = EntityState.Added; // 设置实体状态为新增
    context.SaveChanges(); // 保存更改并提交到数据库
}

以下是一个示例代码片段，演示如何通过实体对象状态更新现有数据：

//修改博客
using (var context = new BlogContext())
{
    var blogToEdit= context.Blogs.Find(id); // 获取实体
    context.Entry(blogToEdit).State = EntityState.Modified; // 设置实体状态为修改
    blog.Title= "新的博客标题"; // 修改属性值
    context.SaveChanges(); // 保存更改并提交到数据库
}

以下是一个示例代码片段，演示如何通过实体对象状态删除数据：

//删除博客
using (var context = new BlogContext())
{
    var blogToDelete= context.Blogs.Find(id); // 获取要删除的实体
    context.Entry(blogToDelete).State = EntityState.Deleted; // 设置实体状态为删除
    context.SaveChanges(); // 保存更改并提交到数据库，这将导致实体从数据库中删除
}

1.3 实体跟踪机制会带来性能问题

实体跟踪机制使得对数据库的更改操作更加简单和高效，因为应用程序只需修改实体对象的属性，而不需要手动编写SQL语句。

需要注意的是:
实体跟踪机制在某些情况下可能会带来性能问题，特别是在处理大量实体对象时。在这种情况下，可以考虑使用EF Core的无跟踪查询功能，或者手动控制实体对象的更改跟踪。

二、什么时候禁用跟踪机制

2.1 场景一：只读查询

在Entity Framework Core中，如果你想禁用跟踪，可以使用AsNoTracking()方法。当你对数据库进行查询时，EF Core默认会跟踪查询返回的实体，这样在后续的操作中可以自动处理相关的变更，例如自动更新数据库。

但是，在某些情况下，你可能不希望EF Core跟踪查询返回的实体，比如当你只是读取数据而不打算修改它们时。在这种情况下，你可以使用AsNoTracking()方法来查询实体，这样EF Core就不会为这些实体创建上下文，也不会跟踪它们的状态变化。这样做可以降低内存的使用，因为EF Core不再需要维护实体的状态。

下面是一个使用AsNoTracking()方法的示例：

//实例化上下文对象，并做非跟踪式的查询（使用AsNoTracking方法））
using (var context = new BlogContext())
{
    var blogs = context.Blogs.AsNoTracking() //禁用跟踪
                             .ToList();      //转成集合
}

在这个例子中，我们通过调用AsNoTracking()方法来禁用对查询结果中Blog实体的跟踪。然后，我们调用ToList()方法来执行查询并将结果加载到内存中。由于使用了AsNoTracking()方法，EF Core不会跟踪这些实体的状态变化，因此也不会在后续操作中自动更新数据库。

2.2 场景二：批量添加

再比如有这样一个场景：要批量获取内部网站用txt生成的日志，在闲时把日志插入到MySql数据库做分析。因为测试数据不是很多，批量插入数据很快完成，效率很高。但是部署到线上问题来了，随着数据量增大变得越来越慢。这时，只需加一句代码就可以让EF批量插入数据性能飙升。

性能优化前代码：

//
BlogContext _dbContext;
...
public async void AddRangeAsync(List<T> entities)
{
    await _dbContext.AddRangeAsync(entities);
    await _dbContext.SaveChangesAsync();
}

性能优化后代码：

//
BlogContext _dbContext;
...
public async void AddRangeAsync(List<T> entities)
{
    //批量添加需要将AutoDetectChangesEnabled给位false
    _dbContext.ChangeTracker.AutoDetectChangesEnabled = false;
    await _dbContext.AddRangeAsync(entities);
    await _dbContext.SaveChangesAsync();
}

以上代码把AutoDetectChangesEnabled属性设置为false，把自动检测更改的功能禁用了。

对于插入操作，无论AutoDetectChangesEnabled的值为true还是false，都可以成功插入数据。因为插入操作本身就是一种新增操作，无需进行实体的更改检测。所以在批量插入时，建议把AutoDetectChangesEnabled设置为false，这样就可以提高性能。

小结

本次分享了EF的实体跟踪机制，为了提高性能，我们可以在只读查询和做批量添加的时候禁用实体跟踪。当然批量添加的性能提升还可以通过使用第三方扩展如Z.EntityFramework.Extensions.EFCore 扩展，或是直接执行原生SQL或存储过程等方法，这个我们在后期继续分享。
如果本文对你有启发，请评论+点赞+关注。

采石之人