EF Core 查询变慢时如何定位并优化（减少 SQL…

当 EF Core 或 DbContext 查询慢、SQL 语句过多、出现 N+1、深分页变慢或索引未生效时，按日志→最小改动→复测的流程优化。

适用场景

解决思路

1. 先捕获生成的 SQL：开启命令日志 `optionsBuilder.LogTo(Console.WriteLine, LogLevel.Information)`，或在 appsettings.json 中设置 `"Microsoft.EntityFrameworkCore.Database.Command": "Information"`；用 `.TagWith("...")` 标记查询以便在日志中定位；在每次改动前后统计一个慢操作执行了多少条语句、每条返回多少行。
2. 每次只应用一个改动并重新测量，优先选择能减少往返次数、重复行、扫描或每次调用翻译成本的做法，而不是微优化。
3. 保持谓词可 sargable——绝不要把带索引的列包在函数里：`CreatedAt.Year == y`、`CreatedAt.Date == d`、`ToLower(Name) == n`、`Price * 1.1 > x`、前导通配符 `LIKE '%foo'` 都会强制逐行计算，导致即使有索引也全表扫描，再加索引也没用；应改写成让列保持裸露的半开区间，例如用 `var start = new DateTime(year, 1, 1); db.Logs.Where(l => l.CreatedAt >= start && l.CreatedAt < start.AddYears(1));` 替代 `db.Logs.Where(l => l.CreatedAt.Year == year);`。
4. 对大小写不敏感文本：比较已存储的规范化列，而不是 `ToLower(...)`/`ToUpper(...)`。
5. 对计算表达式：与预先算好的常量比较，而不是 `column * k > x`。
6. 不要对列做类型转换：对 `column.ToString()` 的谓词（例如匹配数字或日期的文本形式 `total.ToString().StartsWith(p)`）会对每行应用函数，且常常根本无法翻译成 SQL，导致客户端求值把整表拉进内存；应改用类型化列上的真实比较或范围过滤。
7. 子串搜索：`name.Contains(term)` 会变成无法走索引、只能全表扫描的 `LIKE '%term%'`；尾随通配符前缀（`name.StartsWith(term)` → `'term%'`）可以走索引 seek。当可接受前缀匹配时锚定搜索——这会改变匹配的行，先确认行为——大表上的真正子串或模糊搜索应放在全文索引之后。
8. 验证：执行计划显示 seek/index 而非 scan，且耗时下降；如果该列确实没有索引，在谓词已 sargable 之后再添加索引。
9. 编译高频执行的查询：在复用 context 上以极高频率运行同一查询形状的热路径上，EF Core 每次调用都会重新解析 LINQ 表达式树并探测查询缓存；当查询已最小化（索引查找或小投影）且 `AsNoTracking` 等只读优化无收益时，用 `EF.CompileQuery` / `EF.CompileAsyncQuery` 编译一次并复用委托，例如 `private static readonly Func<AppDbContext, int, ProductListItem> GetProduct = EF.CompileQuery((AppDbContext db, int id) => db.Products.Where(p => p.Id == id).Select(p => new ProductListItem(p.Id, p.Name, p.Price)).First());`，委托为 `static`（只编译一次），参数为 `DbContext` 加各查询参数；仅用于极高频率执行同一查询形状的端点或循环，对一次性查询无用。
10. 验证：热循环平均耗时下降且结果一致。
11. 消除 N+1 并避免懒加载：同一 `SELECT` 每行重复一次（循环内访问导航属性）就是 N+1；用 `Select` 投影聚合或 `Include` 预加载在一次往返中加载关联数据，例如 `var summaries = await db.Orders.Select(o => new OrderSummary(o.Id, o.Items.Count, o.Items.Sum(i => i.Price))).ToListAsync();`；优先投影或 `Include` 而非懒加载，懒加载是 N+1 的主因并强制同步 I/O；在服务端应用中不要启用 `Microsoft.EntityFrameworkCore.Proxies`，也不要为懒加载把导航属性标记为 `virtual`。
12. 验证：无论行数多少，查询次数固定且很小。
13. 拆分多个集合 Include：在一条查询中 `Include` 两个或更多集合导航会成倍增加行（笛卡尔爆炸）并重复父数据；使用 `AsSplitQuery()` 让每个集合在自己的语句中加载，并按唯一键 `OrderBy` 以便行能正确拼接，例如 `db.Blogs.Include(b => b.Posts).Include(b => b.Contributors).AsSplitQuery();`。
14. 验证：每条语句的行数大幅下降，总耗时改善。
15. 过滤并分页；优先 keyset 而非 offset：用 `Where` 约束大结果集，用 keyset（seek）分页而非 `Skip`/`Take`（深页仍会扫描并丢弃跳过的行），例如 `db.Orders.Where(o => o.Id > lastSeenId).OrderBy(o => o.Id).Take(pageSize);`；按唯一、稳定、有索引的键排序（排序列不唯一时加决胜键）；keyset 按“最后看到的键”而非页码分页，会改变方法输入；当固定签名不允许就地切换时，仍应指出深 offset 扫描并建议 keyset。
16. 验证：从早期页到深页延迟大致保持恒定。
17. 添加缺失的索引：把过滤移入 SQL 或让谓词 sargable 只消除了客户端浪费，但 `WHERE` 或 `ORDER BY` 的列若没有索引，数据库内仍会全表扫描，频繁执行的查询每次调用都会重新扫描；因此要把索引覆盖与查询重写分开审计：对每个查询检查其过滤和排序列是否有索引支撑；实体键和外键按约定有索引，但其他列——状态标志、state/enum 字段、时间戳、名称——除非模型配置，通常没有；当热查询在这样的无索引列上过滤或排序时，明确建议添加索引，即使重写后的查询已返回正确行——索引是代码改动本身无法提供的独立修复（若谓词不 sargable，先修谓词，新索引无法帮助由列上函数导致的扫描）。
18. 如果 EF Core 拥有 schema，在模型中添加索引并迁移，例如 `modelBuilder.Entity<Order>().HasIndex(o => new { o.CustomerId, o.CreatedAt });`（等值列在前，范围/排序列在后），然后用 `dotnet ef migrations add ...` 创建迁移；未经用户明确批准，不要用 `dotnet ef database update`（或任何写数据库的等价操作）应用它——应用迁移会修改数据库，所以只添加迁移、展示给用户，让用户审阅后自行运行 update；如果 EF Core 不拥有 schema，向管理数据库的人建议同样的索引；不要过度索引——每个索引都会拖慢写入。
19. 验证：执行计划使用 seek/index 而非 scan。
20. 用基于集合的批量更新和删除：用 `ExecuteUpdateAsync`/`ExecuteDeleteAsync`（EF Core 7+）替代 load-mutate-`SaveChanges` 循环——一条语句，不物化实体，例如 `await db.Products.Where(p => p.LastSoldDate < cutoff).ExecuteUpdateAsync(s => s.SetProperty(p => p.IsActive, false));`；这些方法绕过变更跟踪器和 EF 端级联行为——需显式应用相关更改。
21. 验证：只有一条带 `WHERE` 的 `UPDATE`/`DELETE`，且前面没有 `SELECT`。
22. 避免常见陷阱：不要把带索引的列包在 `.Year`/`.Date`/`ToLower`/算术中，应改写成对裸露列的 sargable 范围/比较；不要用加索引来修复非 sargable 谓词导致的扫描，先修谓词，列裸露前索引无用；不要把过滤重写进 SQL 却让热查询留在无索引列上，服务端扫描仍是扫描，应同时建议在过滤/排序列上加索引；不要编译只偶尔运行的查询，只编译真正热、高频的查询形状；不要用懒加载（代理 / `virtual` 导航）导致 N+1 和强制同步 I/O，应预加载（`Include`）或投影并保持查询异步；不要在 `Where`/`Select` 之前 `ToList()`/`AsEnumerable()`，保持查询为 `IQueryable` 以便过滤/投影在 SQL 中执行。

适用边界 · 注意事项

• 代码使用 Dapper 或原生 ADO.NET 而非 EF Core：直接回答 SQL/索引/查询计划问题，不要引入 `DbContext`，也不要推荐 `AsNoTracking`、`Include`、`AsSplitQuery` 或其他 EF Core API。
• 不要对只偶尔运行的查询使用 `EF.CompileQuery`/`EF.CompileAsyncQuery`，只编译真正热、高频的查询形状。
• 未经用户明确批准，不要用 `dotnet ef database update` 或任何写数据库的等价操作应用迁移。