EF Core查询性能优化核心是按需加载、减少开销、避免重复：启用AsNoTracking提升只读查询速度2–5倍；用select投影替代include避免笛卡尔积；禁用懒加载并用显式加载或拆分查询堵住N+1漏洞。
EF Core 查询性能优化的核心在于“按需加载、减少开销、避免重复”。默认行为往往偏保守，适合通用场景，但对高并发或大数据量应用来说，容易成为瓶颈。关键不是全盘禁用某项功能，而是根据读写需求精准控制。
只读查询一律用 AsNoTracking
只要不打算修改查出来的数据，就该关掉变更跟踪。它省下的不只是时间，还有内存和上下文管理成本。
- 单次查询加 .AsNoTracking() 最直接，比如报表页、列表页、API只读接口
- 若整个应用以只读为主，可在 OnConfiguring 中设全局默认：
optionsBuilder.UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking); - 需要更新时再显式加 .AsTracking()，不影响灵活性
- 实测在中等复杂度模型下，提速 2–5 倍；10 万条记录场景下，平均耗时可从 700μs 降至 350μs 左右
别让数据“拖家带口”回来
加载一个实体，却顺手把所有导航属性、子表、孙表全拉下来，是常见性能杀手。尤其是一对多关系里子表数据量大时，sql 会生成笛卡尔积，结果集爆炸式膨胀。
- 优先用 Select 投影到 DTO 或匿名类型，只取真正需要的字段
- 避免滥用 Include/ThenInclude，特别是多级嵌套（如 .Include(x => x.Cs).ThenInclude(x => x.D1s).ThenInclude(…)）
- 真要关联数据，考虑拆分查询（Split Queries），用多次简单查询替代一次巨复杂 JOIN
- 示例：查宫殿列表只需名称和业主姓名？那就 .Select(p => new { p.Id, p.Name, OwnerName = p.Owner.Name })，别 Include 整个 Owner 实体
堵住 N+1 查询这个漏洞
表面看代码简洁，实际可能发起几十上百次数据库请求——比如先查订单列表，再循环访问每个订单的 Items 属性。
- 禁用懒加载（Lazy Loading），它默认关闭最好，开了更易踩坑
- 明确知道要哪些关联数据，就用 Include 一次性预加载
- 不确定是否要用全部关联数据？改用 显式加载（Entry(entity).Collection(e => e.Items).Load()） 按需触发
- 批量查多个主表 ID 对应的子表数据？别在循环里查，先收集 ID 列表，再用 .Where(i => ids.Contains(i.ParentId)) 一次捞完
其他实用加速点
这些不常被提起，但一用见效：
- DbContext 实例池化：用 AddDbContextPool 替代 AddDbContext，复用上下文实例，减少 GC 压力和初始化开销
- 模糊查询用 EF.Functions.Like，比 Contains/StartsWith 生成的 SQL 更高效（底层走 LIKE 而非 CHARINDEX）
- 高频只读查询配缓存：用 IMemoryCache 手动缓存结果，或引入 EFCache 拦截器 + FromCache() 扩展
- 分页必须用 Skip/Take，严禁先 ToList 再内存分页——数据一过万就卡死
基本上就这些。不复杂，但容易忽略。每一条都对应真实慢查询场景，挑最痛的一两条先改，效果立竿见影。