【性能优化】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或存储过程等方法,这个我们在后期继续分享。
如果本文对你有启发,请评论+点赞+关注。
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:veading@qq.com进行投诉反馈,一经查实,立即删除!