用Entity Framework Core（EF Core）开发时，性能问题往往像突然发现家里漏水一样让人头疼。明明功能都实现了，为什么页面加载越来越慢？本文将带你解锁三大进阶技能，用真实代码示例教你如何从查询优化、事务管理到批量操作全方位提升性能。
一、查询优化：你的LINQ可能是性能杀手
1.1 避免N+1查询陷阱
当导航属性加载不当，会触发"偷偷多跑"的数据库查询。通过代码对比来感受差异：
// 反模式：每次循环触发数据库查询（N+1次查询）
var blogs = context.Blogs.ToList();
foreach (var blog in blogs)
{
var posts = blog.Posts.ToList(); // 每次访问触发查询
}
// 正确做法：预先加载（1次查询）
var optimizedBlogs = context.Blogs
.Include(b => b.Posts) // 显式加载导航属性
.ToList();
在调试模式下打开查询日志，你会发现两种方式的SQL执行次数天差地别。注意Include方法的级联使用规则，避免加载不必要的数据。
1.2 追踪还是不追踪？这是个问题
只读场景关闭变更追踪能显著减少内存开销：
var readOnlyData = context.Products
.AsNoTracking() // 关闭变更追踪
.Where(p => p.Price > 100)
.ToList();
可以通过AsTracking()方法灵活控制特定查询的追踪状态。实测显示，处理10万条数据时内存占用可降低40%。
1.3 SQL执行计划不可见？
通过这个配置解密底层执行逻辑：
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
optionsBuilder
.UseSqlServer(connectionString)
.LogTo(Console.WriteLine, LogLevel.Information) // 输出SQL日志
.EnableSensitiveDataLogging(); // 显示参数值
}
结合SQL Server Management Studio的Actual Execution Plan功能，能直接看到索引是否被有效利用。
二、事务管理：金融级操作的安全保障
2.1 自动事务的局限性
默认的SaveChanges自带事务，但不适合跨多个操作：
using var transaction = await context.Database.BeginTransactionAsync();
try
{
// 操作1：扣减库存
var product = await context.Products.FindAsync(1);
product.Stock -= 1;
// 操作2：生成订单
context.Orders.Add(new Order { ProductId = 1 });
await context.SaveChangesAsync(); // 统一提交
await transaction.CommitAsync();
}
catch
{
await transaction.RollbackAsync();
throw;
}
特别注意事务作用域的生命周期管理，避免长时间持有事务锁。
2.2 跨库事务处理
在微服务架构中，可以结合消息队列实现最终一致性：
// 使用CAP框架实现分布式事务
await context.Database.BeginTransactionAsync();
await publisher.PublishAsync("order.created", new { OrderId = 123 });
await context.SaveChangesAsync();
await context.Database.CommitTransactionAsync();
虽然EF Core本身不支持跨数据库事务，但通过业务逻辑层的补偿机制可以实现可靠的数据一致性。
三、批量操作：万级数据处理实战
3.1 原生SQL的精准打击
直接执行SQL可以绕过变更追踪：
// 批量更新
var updateCount = context.Database.ExecuteSqlInterpolated(
$"UPDATE Products SET Price = Price * 1.1 WHERE CategoryId = {categoryId}");
// 参数化查询保证安全
var deleteCount = context.Database.ExecuteSqlRaw(
"DELETE FROM Logs WHERE CreateTime < {0}", DateTime.Now.AddDays(-30));
建议为高频更新操作创建存储过程，通过FromSqlRaw调用更安全。
3.2 扩展库性能暴增
使用Z.EntityFramework.Plus实现批量删除：
// 需要安装Z.EntityFramework.Plus.EFCore
context.Products
.Where(p => p.IsDeleted)
.Delete(); // 生成单个DELETE语句
// 批量插入
var batchInsert = new List<Product>(10000);
//...填充数据
context.BulkInsert(batchInsert);
实测显示，批量插入10万条数据的时间从默认的180秒降到3秒以内。注意要配合DbContext池化使用避免资源浪费。
四、典型应用场景
- 电商系统：订单创建需同时操作库存表、订单表、日志表，必须使用显式事务
- 物联网系统：高频传感器数据存储适用批量插入
- 报表系统：复杂查询应配合AsNoTracking和原生SQL使用
- 消息系统：消息已读状态更新适合ExecuteUpdate
五、技术对比手册
| 技术手段 | 优势 | 劣势 |
|---|---|---|
| 显式事务 | 保证原子性，回滚可靠 | 代码复杂度增加 |
| 批量扩展 | 性能提升显著 | 需要第三方库支持 |
| AsNoTracking | 内存占用低，查询速度快 | 无法直接更新实体 |
| 原生SQL | 完全控制执行逻辑 | 丧失平台兼容性 |
六、重要注意事项
- 在事务中执行DDL语句时要检查数据库兼容性
- 批量操作期间慎用ChangeTracker
- 长期不释放的事务会导致数据库死锁
- 异步方法要全程使用async/await上下文
- 使用Any()判断存在性比Count()更高效
七、经验总结
通过合理配置查询策略、事务范围控制和批量操作，可以使EF Core处理百万级数据的性能接近原生ADO.NET。关键是要根据业务场景灵活选择工具，就像老司机知道什么时候该换挡加速，什么时候该踩刹车。记住：没有银弹技术，只有合适的技术组合。
评论