当前位置： 主页 > 新闻动态 > 技术帮助

EF Core如何进行性能优化 EF Core查询性能优化技巧

发布日期： 2026-01-15 阅读量： 作者： 畫卷琴夢

EF Core查询性能优化核心是按需加载、减少开销、避免重复：启用AsNoTracking提升只读查询速度2–5倍；用Select投影替代Include避免笛卡尔积；禁用懒加载并用显式加载或拆分查询堵住N+1漏洞。

EF Core 查询性能优化的核心在于“按需加载、减少开销、避免重复”。默认行为往往偏保守，适合通用场景，但对高并发或大数据量应用来说，容易成为瓶颈。关键不是全盘禁用某项功能，而是根据读写需求精准控制。

只读查询一律用 AsNoTracking

只要不打算修改查出来的数据，就该关掉变更跟踪。它省下的不只是时间，还有内存和上下文管理成本。

单次查询加 .AsNoTracking() 最直接，比如报表页、列表页、API只读接口
若整个应用以只读为主，可在 OnConfiguring 中设全局默认：
optionsBuilder.UseQueryTrackingBehavior(QueryTrackingBeha
vior.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 再内存分页——数据一过万就卡死

基本上就这些。不复杂，但容易忽略。每一条都对应真实慢查询场景，挑最痛的一两条先改，效果立竿见影。

上一篇: iPhone17Pro对比iPhone16Pro的亮点？AI

下一篇: iPhone17Pro与iPhone16Pro的区别？性能优

南昌壹佳企网络通信有限公司

关注官方公众号

关于我们

服务项目: 网站建设运营推广小程序短视频

推广方案

案例中心: 网站案例广告设计营销传播影像大片