EF Core 避坑指南：查询慢、循环查询、并发更新问题如何解决

EF Core 极大提升了 .NET 的数据访问效率，但"用得好是 ORM，用不好是性能杀手"。

很多同学上线后才发现接口变慢、CPU 飙高、数据被覆盖------问题往往不在数据库，而在 EF Core 的使用姿势上。

本文聚焦三个高频"事故区"：查询慢、循环查询（N+1）、并发更新，结合 .NET 8 + EF Core 8 给出可落地的解决方案。

一、查询慢：90% 的性能问题都在这

1. 典型症状

接口响应时间随数据量线性增长
SQL Server Profiler / EF Core Logging 中看到大量 SELECT *
返回字段远超实际需要
一次请求触发几十条 SQL

2. 常见原因 & 解决方案

✅ 坑 1：全表 / 全字段查询

复制代码

// ❌ 错误示例
var users = await _context.Users.ToListAsync();

问题：

拉取全部数据
包含所有字段（密码哈希、长文本等）

✅ 正确做法：只查需要的字段

复制代码

// ✅ 投影查询
var users = await _context.Users
    .Select(u => new UserDto
    {
        Id = u.Id,
        Name = u.Name,
        Email = u.Email
    })
    .ToListAsync();

📌 要点：

永远优先考虑 Select
DTO ≠ Entity，不要混用

✅ 坑 2：IEnumerable vs IQueryable

复制代码

// ❌ 危险
IEnumerable<User> users = _context.Users;
var result = users.Where(u => u.Age > 18).ToList();

问题：

Where 在内存中执行，数据库把整张表拉回来。

✅ 正确做法：保持 IQueryable

复制代码

// ✅ 安全
IQueryable<User> users = _context.Users;
var result = await users.Where(u => u.Age > 18).ToListAsync();

📌 口诀：

IQueryable = SQL 还没执行，IEnumerable = SQL 已结束

✅ 坑 3：滥用 AsNoTracking

复制代码

// ❌ 读操作却跟踪实体
var user = await _context.Users.FirstAsync(u => u.Id == id);

问题：

EF Core 会开启变更追踪，消耗内存和 CPU。

✅ 只读场景一定用 AsNoTracking

复制代码

var user = await _context.Users
    .AsNoTracking()
    .FirstAsync(u => u.Id == id);

📌 适用场景：

API 查询
报表
列表页

📌 不适用：

后续要 SaveChanges() 的实体

✅ 坑 4：分页在内存中做

复制代码

// ❌ 错误
var list = _context.Users.ToList().Skip(100).Take(10);

✅ 正确做法：SQL 层面分页

复制代码

var list = await _context.Users
    .OrderBy(u => u.Id)
    .Skip(100)
    .Take(10)
    .ToListAsync();

📌 EF Core 会翻译成 OFFSET / FETCH，性能天差地别。

二、循环查询（N+1 问题）：最隐蔽的性能炸弹

1. 什么是 N+1 问题？

先查 1 次主表，再对每一条记录查 1 次关联表，共 N+1 次 SQL。

2. 典型错误示例

复制代码

// ❌ N+1 问题
var orders = await _context.Orders.ToListAsync();

foreach (var order in orders)
{
    var user = await _context.Users
        .FirstAsync(u => u.Id == order.UserId);
}

假设 1000 条订单 → 1001 次 SQL 查询

3. 解决方案一：Include（最常用）

复制代码

// ✅ 一次 JOIN
var orders = await _context.Orders
    .Include(o => o.User)
    .ToListAsync();

📌 适用：

关联数据量不大
强一致性读取

⚠️ 注意：

Include 过多会导致笛卡尔积爆炸
不要 Include(a => a.B).Include(a => a.C).Include(a => a.D)

4. 解决方案二：Select + 投影（推荐）

复制代码

// ✅ 高效且无 N+1
var orders = await _context.Orders
    .Select(o => new OrderDto
    {
        OrderId = o.Id,
        UserName = o.User.Name
    })
    .ToListAsync();

📌 优点：

SQL 最少
字段最少
性能最好

✅ 这是生产环境的最优解

5. 解决方案三：显式加载（特定场景）

复制代码

// ✅ 按需加载
foreach (var order in orders)
{
    await _context.Entry(order)
        .Reference(o => o.User)
        .LoadAsync();
}

📌 仅适合：

管理后台
低频操作
数据量小

三、并发更新：数据被悄悄覆盖

1. 典型事故场景

用户 A 和用户 B 同时编辑同一条记录
A 先保存
B 后保存
A 的修改被 B 覆盖（最后写入胜出）

2. 解决方案一：并发令牌（Concurrency Token）✅ 推荐

Step 1：配置并发字段

复制代码

public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }

    [Timestamp]
    public byte[] RowVersion { get; set; }
}

或在 Fluent API 中：

复制代码

modelBuilder.Entity<Product>()
    .Property(p => p.RowVersion)
    .IsRowVersion();

Step 2：更新时的行为

复制代码

try
{
    product.Name = "New Name";
    await _context.SaveChangesAsync();
}
catch (DbUpdateConcurrencyException ex)
{
    // ✅ 处理并发冲突
    // 提示用户重新加载数据再提交
}

📌 原理：

SQL：WHERE Id = @id AND RowVersion = @rowVersion
版本不一致 → 更新失败 → 抛异常

✅ 这是企业级系统的标准做法

3. 解决方案二：悲观锁（不推荐，但可用）

复制代码

var product = await _context.Products
    .FromSqlRaw("SELECT * FROM Products WITH (UPDLOCK, ROWLOCK) WHERE Id = @id", id)
    .FirstAsync();

📌 缺点：

锁住数据库行
影响并发
容易死锁

📌 仅用于：

金融核心
库存扣减
强一致性要求极高场景

4. 解决方案三：应用层重试（最终一致）

复制代码

int retry = 0;
while (retry < 3)
{
    try
    {
        await _context.SaveChangesAsync();
        break;
    }
    catch (DbUpdateConcurrencyException)
    {
        retry++;
        // 重新加载实体
    }
}

📌 适合：

低冲突概率
非核心业务

四、EF Core 性能优化的"黄金法则"

✅ 查询侧

✅ 永远优先 Select
✅ 只读必加 AsNoTracking
✅ 分页交给数据库
✅ 避免 Count() + ToList() 重复查询
✅ 警惕 Include 的笛卡尔积

✅ 写入侧

✅ 批量操作使用 ExecuteUpdate / ExecuteDelete（EF Core 7+）
✅ 避免循环 Add / Update
✅ 合理使用事务（不要包太大）

✅ 监控侧

✅ 开启 EF Core Logging
✅ 使用 ToQueryString() 查看 SQL
✅ 生产环境接入 Application Insights / OpenTelemetry

五、一张速查表

问题	根因	解决
查询慢	SELECT *	Select 投影
内存暴涨	IEnumerable	保持 IQueryable
N+1	循环中查库	Include / Select
数据覆盖	无并发控制	RowVersion
CPU 高	变更追踪	AsNoTracking
分页卡	内存分页	Skip / Take

六、总结

EF Core 不慢，慢的是用法；EF Core 不坑，坑的是默认行为。

查询：能投影就不实体，能不追踪就不追踪
关联：能一次查完就不要循环查
并发：能用乐观锁就不用悲观锁

掌握这些"避坑点"，你的 .NET 8 + EF Core 项目才能真正做到：

代码优雅、性能强劲、线上稳如老狗。