用 EF Core 写模型这件事做得好的人往往不是代码写得快而是把模型配置当工程来对待。我在这上面吃过的亏几乎都集中在同一个点上模型设计阶段偷懒查询阶段加倍偿还尤其是项目量级上来之后一条没做投影的查询、一个没有显式精度的 decimal 字段都能变成线上事故的源头。这篇文章不讲基础 CRUD直接围绕两件事展开——怎么把模型定义本身优化到不拖后腿怎么在查询使用中把模型的性能潜力榨出来。无论你是刚接触 EF Core 的新手还是已经在老项目里被慢查询折磨的团队这里都有能立即落地的经验我会用实际踩过的坑和配置代码说话不搞虚的。EF Core 发展到 8.x官方默认行为已经足够智能但它仍然遵守着一套严格的翻译规则。你按照规则优化模型它就能生成接近手写 SQL 的查询你绕过规则乱用它就会用隐蔽的方式惩罚你。这篇文章是从一个真实项目的模型重构里提炼出来的里面每一个片段都在线上环境验证过可以直接参考复现。1. 模型设计阶段的优化把实体映射做对1.1 为什么我把 Fluent API 当主力配置方式“实体配置到底用 DataAnnotations 还是 Fluent API”这个问题我回答过太多次。如果是一个几十张表的小项目用特性标注确实省事但只要实体表超过二十张、团队人数超过两个人我强烈建议把结构性配置全部迁到 Fluent API不要再用特性硬撑。原因有几个都很实际。第一是配置的可见性。用 DataAnnotations 时表名、列名、索引、关系分散在实体类的各个属性上模型成员一多代码看起来就像把地图碎片贴满整面墙。用 Fluent API 之后每个实体一个配置类文件路径即定位路径审代码的人顺着文件找效率完全不同。实体里只留干净的属性定义表结构相关的信息全部移动到IEntityTypeConfigurationT实现类中比如下面的写法public class OrderConfiguration : IEntityTypeConfigurationOrder { public void Configure(EntityTypeBuilderOrder builder) { builder.ToTable(orders, schema: sales); builder.HasKey(o o.Id); builder.Property(o o.OrderNo) .HasColumnName(order_no) .HasMaxLength(32); builder.HasOne(o o.Customer) .WithMany(c c.Orders) .HasForeignKey(o o.CustomerId) .OnDelete(DeleteBehavior.Restrict); } }第二是表达能力。DataAnnotations 覆盖不了全部场景HasQueryFilter全局过滤、HasComment列注释、IsRowVersion行版本、HasPrecision精度、复合索引排序方向这些用特性要么写不出来要么写出来非常别扭。Fluent API 才是 EF Core 配置语法的完整形态。你在模型优化过程中要做的绝大部分结构性调整都只能在 Fluent API 里完成。第三是迁移与复用。配置集中在类里面跟着 DbContext 走换数据库、升级 EF 版本都有集中修改的入口。特性写在实体上将来如果实体被复制到另一个项目还会把历史包袱一起带过去。这其实是一个工程化的问题也是后面编译模型管理的基础。配置不集中后面所有优化手段都会受阻。1.2 精度与类型映射配置里最容易被偷懒的地方“decimal 默认映射成 decimal(18,2)够了吧” 这句话我听太多次了。第一次在真实项目里被精度坑是税率字段业务算出来 0.174存进数据库变成了 0.17第二个月对账的时候直接炸了。原因很简单decimal的默认长度不满足业务的 6 位小数需求。自那以后我定了一条规矩模型中所有decimal字段必须显式HasPrecision绝不吃默认值。builder.Property(o o.TotalAmount).HasPrecision(18, 2); builder.Property(o o.TaxRate).HasPrecision(10, 6); builder.Property(o o.UnitPrice).HasPrecision(18, 4);除了精度字符串列类型也要留心。SQL Server 下string默认映射成nvarchar(max)除非你写了HasMaxLength。一个没有任何长度限制的字符串列在索引和排序上都是麻烦。我见过一个用户表Description 一列是 max业务偶尔对 Description 排序结果查询计划直接选了排序算子慢得没法看。后来改成HasMaxLength(200)配合索引同样的查询瞬间就下来了。数据库对 max 类型列建索引也有额外限制所以能固定长度就固定长度别给自己埋雷。DateTime也是常见的微妙差异。SQL Server 里datetime和datetime2精度不一样前者精确到 3.33ms后者到 100ns。假如你跨库或跨系统比对时间建议显式HasColumnType(datetime2)MySQL 下则可能是HasColumnType(datetime(6))。这类差异在开发环境几乎测不出来上线后被用户反馈“时间对不上”才头疼。所以模型配置阶段凡是涉及数值精度、时间精度、字符串长度的都要显式写清楚这是成本最低的优化。还有命名规范。团队规范里我建议所有列名走数据库惯例比如order_no、created_at。EF Core 默认把属性名当列名CreatedAt直接建列也合法但和团队里已有的 SQL 规范冲突时就用HasColumnName统一。别小看这个等你需要 DBA 帮忙排查线上慢查询时他们会感谢你的。1.3 索引配置加容易删难模型优化的第二个大头是索引。很多人只要发现查询慢就builder.HasIndex加一个加到后来索引比表还大。我得泼盆冷水索引不是免费的。每个索引都占存储、拖慢插入和更新尤其是在高并发写入系统里索引就是写入路径上的额外税建得越多代价越大。索引配置顺序我向来固定主键交给 EF Core 默认外键列如果业务高频按外键过滤检查迁移脚本里的索引生成情况单一高频 WHERE 列加单列索引经常一起出现的列做复合索引注意列顺序排序列用IsDescending配合业务唯一键加唯一索引顺便承担约束作用。这里最容易翻车的是复合索引顺序。以订单为例如果业务固定按CustomerId CreatedAt查询索引应该是builder.HasIndex(o new { o.CustomerId, o.CreatedAt }) .IsDescending(false, true);如果写成CreatedAt CustomerId那按CustomerId过滤的查询基本用不上这个索引走了 Index Scan 也不会高效。这其实是 B 树索引的基本原则和 EF Core 本身无关但很多开发是在 Migration 脚本里才第一次跟它碰面发现执行计划不对劲时才回头改配置一来一回浪费不少时间。还有一点容易被忽略IsDescending只改变索引排序方向但不同数据库对降序索引的支持不太一致。SQL Server 和 MySQL 8 都支持降序索引老版本 MySQL 可能不支持。这块建议在迁移脚本里人工确认不要只看迁移是否成功真要上线了才发现索引方向没起作用分页排序的性能问题就来了。索引优化的核心原则其实一句话索引只加在高频路径上复合索引列序按区分度排写完索引后拿真实 SQL 执行计划验证。加索引很容易等 DBA 因为存储膨胀来找你删索引的时候通常已经晚了。2. 查询使用层面的模型优化让 EF Core 少干活2.1 投影裁剪是第一级优化模型配置得再漂亮查询不会用照样白搭。第一级优化就是把出库的数据量压到最小。直接context.Orders.ToList()是最省事的写法EF 会翻译成SELECT * FROM Orders。如果表有 25 个字段业务只要其中 3 个剩下的 22 个字段全在白白传输和初始化。数据量小的时候无所谓但一张千万行的大表查询结果集的 IO 差异是数量级的。改成投影之后var list await context.Orders .Where(o o.Status OrderStatus.Shipped) .OrderByDescending(o o.ShippedAt) .Select(o new OrderListItemResponse { Id o.Id, OrderNo o.OrderNo, ShippedAt o.ShippedAt }) .ToListAsync();这段 SQL 干净、结果集小、对象初始化快。在接口层返回 DTO/Response 而不是实体本身就是一种模型边界控制。投影还有一个隐藏优点它可以避免 EF Core 因导航属性而产生一些多余的 JOIN。模型里如果配置了必需关系某些情况下即使你没写IncludeEF 也可能在查询主表时多做连接投影会明确告诉它你只要哪个表和哪几列翻译出来的 SQL 意图更清晰。投影时需要小心一个点尽量别先查匿名对象再回内存里手动装配更多字段。那个匿名对象查询本身没问题但如果你在内存里继续访问导航属性可能重新触发额外的加载。投影的边界要和业务逻辑边界对齐别把 EF 的活搬到内存再干一遍否则就是打着优化旗号又制造 N1得不偿失。2.2 AsNoTracking 的选择和边界EF Core 的默认行为是对查询出来的实体启动变更跟踪这是它做更新优化的基础但代价不小ChangeTracker 要保存快照、标记状态、维护关系很多只读查询完全没必要走这条链路。AsNoTracking()用在只读查询是性能提升最直接的手段之一而且几乎没有副作用。尤其在做列表查询、报表聚合时加与不加的差距体感很明显。但边界要说清楚如果你查询出来的实体要在上下文里修改并保存就不要加。例如var order await context.Orders.AsNoTracking() .FirstAsync(o o.Id id); order.Status OrderStatus.Completed; await context.SaveChangesAsync();这段代码里ChangeTracker 根本不认识orderSaveChangesAsync不会产生任何 UPDATE。要么去掉AsNoTracking要么手动Attach再标记状态。我在项目里见过这个 bug排查的人一脸懵因为单看代码完全没问题结果就是数据一直没更新线上订单状态卡住这种隐性 bug 比编译错误难找得多。如果你的场景是“要查一个复杂对象图又不想跟踪修改”可以考虑AsNoTrackingWithIdentityResolution()。它会对相同主键的实体做去重解决无跟踪场景下同一个实体出现多份副本的问题代价是额外的对象字典维护所以不要全局默认用。另外AsNoTracking是查询级的不是全局的。你们可以在DbContext构造函数里写ChangeTracker.QueryTrackingBehavior QueryTrackingBehavior.NoTracking做成全局默认但我不建议这样它会掩盖太多细节让“可写查询”的默认路径变成反直觉新手很容易踩坑。显式在每个查询上加反而更安全代码审查时也看得清楚。2.3 加载策略权衡Include、显式加载、延迟加载加载策略是模型优化的核心决策之一。EF Core 默认不启用延迟加载代理除非你自己装包并开启UseLazyLoadingProxies()。我在文章前面说过强烈建议生产项目不要开启延迟加载理由只有一个它会在循环里默默产生 N1 条 SQL而你代码里看起来就是一行访问导航属性的语句问题被藏得很深。用贪婪加载Include也要克制。Include一个引用导航Reference大多数时候没太大问题但Include多个集合导航CollectionSQL 会变成大 JOIN行数膨胀得非常快。假设 A 有 100 条 B、每条 B 有 50 条 C一次把 A-B-C 都 Include 进来结果集就是 5000 行查询 100 个 A 就是 50 万行这就是笛卡尔爆炸。想避免 JOIN 撑爆用AsSplitQuery()后面专门讲这里先说什么时候用哪种加载方式。场景推荐方案原因只查主实体直接投影或查询最小 IO主实体 一个引用导航Include单查询一次 JOIN 可接受主实体 多个集合导航AsSplitQuery或投影避免结果集膨胀主实体 按需加载关联显式加载LoadAsync灵活控制 SQL 条数循环里访问导航属性显式加载 / 一次性 Include避免 N1显式加载是我个人非常喜欢的方式。先拿主实体再在需要时LoadAsyncSQL 条数可控也没有延迟加载的隐蔽性。缺点是代码多写几行但换来的是可观测性和可控性。举个例子var order await context.Orders.FirstAsync(o o.Id orderId); await context.Entry(order).Collection(o o.Items).LoadAsync();最多两条 SQL主查询加关联查询行为完全可预测。这里要提醒无论用哪种加载只要你把实体返回给上层并且在那个层又访问了未加载导航属性就可能触发 N1启用延迟加载时或空引用未启用时。所以“在哪层查询、在哪层访问导航属性”需要形成团队约定。我的建议是导航属性只在服务层内部访问出服务层之前全部转成 DTO这条约定落实之后N1 问题能少一大半。3. 高级查询与真正的“优化后模型”拆分查询与编译模型3.1 AsSplitQuery根治笛卡尔爆炸讲Include时提过的笛卡尔爆炸EF Core 5.0 之后提供了AsSplitQuery()这个官方解法。原理很简单把一条带多层 JOIN 的大 SQL 拆成多条 SQL每条负责加载一个层级的导航数据最后在内存中通过关系修补relationship fixup组装出完整对象图。var orders await context.Orders .Include(o o.Items) .ThenInclude(i i.HistoryRecords) .Where(o o.ShippedAt startDate) .AsSplitQuery() .ToListAsync();使用后EF 会生成多条语句比如先查 Orders再查 Items再查 HistoryRecords每条 SQL 的结果集都比大 JOIN 小得多。坏处是网络往返次数变多所以它不是万能药不是所有查询都适合拆。我经验里的判断标准很简单Include超过两个集合导航或者集合数据量预期较大时直接AsSplitQuery()只Include一个引用导航时单查询完全没问题混合场景且不确定就先用拆分查询看效果再根据监控数据回退。还要留意一个版本特性AsSplitQuery和Skip/Take的分页语义在不同 EF Core 版本里表现不同。EF Core 8 之前Skip/Take被应用到最后一条查询可能导致分页语义不符合直觉EF Core 8 开始对拆分查询的分页处理做了修正按集合分别应用分页。如果团队还停留在 5/6/7用之前最好在你目标版本上做一次行为验证。这种细节官方文档只写了一小段但实际影响业务分页的准确性踩过的人才知道。3.2 Compiled Model编译模型把启动卡顿干到 0.3 秒“优化后的模型”这个标题里的核心其实直指 EF Core 6 引入的编译模型Compiled Model。为了理解它得先知道 EF Core 启动时发生了什么。每次创建第一个DbContext实例时EF 都要扫描程序集里所有 DbContext、实体类、配置类跑一遍约定Convention流程最后构建出内部模型。模型越大这个过程越慢而且每次冷启动都要重来一遍。用过大型项目的人都知道第一次请求要等十几秒的那种难受其实多半不是查询慢而是模型构建慢。编译模型就是把这个耗时的模型构建过程提前到开发阶段做完。用官方提供的dotnet ef dbcontext optimize命令生成一个静态的、只读的模型快照运行时不走反射直接加载。命令示例dotnet ef dbcontext optimize -c AppDbContext --output-dir CompiledModels生成后在OnConfiguring里指定使用protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { optionsBuilder .UseSqlServer(connectionString) .UseModel(AppDbContextModel.Instance); }我拿真实项目测过约 120 个实体、40 个配置类生成编译模型前首次 EF 模型构建耗时约 3.8 秒用上之后降到 0.3 秒以下。这个收益在微服务扩容、容器冷启动场景下尤其明显每次冷启动省下几秒钟对调度和扩容都是实打实的好处。但编译模型有一个硬约束它假设模型在运行时是固定的。你不能再在DbContext构造函数里动态修改modelBuilder也不允许在某些方法中根据环境条件切换模型配置。所以前面第一部分强调“所有配置集中在 IEntityTypeConfiguration”就显得至关重要只有配置静态化编译模型才生成得动、生成得准。每次实体或配置变更后记得重新运行 optimize 命令。这个步骤很容易被遗忘因为本地开发时你不怎么重启进程但生产环境每次部署都会暴露问题。建议把命令写进 CI模型配置文件有变化就自动重新生成别靠人肉记。3.3 Compiled Query 与原生 SQL高频查询的最后一块拼图比编译模型更细一层的是编译查询。EF Core 每次执行 LINQ 查询都要把表达式树解析成查询计划虽然查询计划缓存已经能大幅降低成本但某些极端高频、参数化模式固定的查询用EF.CompileAsyncQuery直接缓存委托连表达式树解析都省了。private static readonly FuncAppDbContext, int, TaskOrder GetOrderById EF.CompileAsyncQuery( (AppDbContext ctx, int id) ctx.Orders.AsNoTracking().FirstOrDefault(o o.Id id)); var order await GetOrderById(context, orderId);不过说实话现代 EF Core 的查询计划缓存已经很强编译查询的收益在多数应用里有限。它值得用的地方往往是“同一查询每秒执行几百次”的内部服务比如订单号查详情、用户 ID 查配置中心这类热点。为了可读性我不建议把所有查询都改成编译查询挑几个真正热点的路径做就行其他保持普通 LINQ 反而更利于维护。原生 SQL 方面FromSqlInterpolated和FromSqlRaw适用于 LINQ 无法干净翻译的场景比如递归 CTE、窗口函数、PIVOT、复杂报表。但有一件事必须守住用户输入永远通过参数化方式传进去绝对不要拼字符串。EF Core 的FromSqlInterpolated会做参数化但FromSqlRaw不会使用时要格外小心。我的取舍原则很明确LINQ 能干净翻译绝不用原生 SQLSQL Server 特有的高性能写法才值得从 LINQ 绕到原生。如果团队里有 DBA让他们参与这里的设计比事后用拦截器发现慢查询要高效得多。4. 模型优化过程中的常见问题与排查实录4.1 模型与数据库漂移上线前最后一根稻草我最怕的不是模型写得差而是模型和数据库悄悄不一致。症状通常很明显应用启动时报InvalidOperationException提示 model backing the context has changed。EF Core 在启动时会拿当前模型和数据库里的迁移历史做比对如果发现模型状态对不上就拒绝启动。这种漂移多半来自三处有人手改了数据库表结构有人改了模型代码却没生成 Migration还有人直接改了 Migration 快照文件。排查方法不复杂生成一个新的空迁移看看Up里面包含了什么如果它想删除某些列或表基本可以断定数据库和模型已经分叉。如果是空迁移说明代码和上一次迁移之间没有结构变更问题可能出在数据库被手改过。知道了原因解决方向就清楚了。但更重要的还是预防我的管理流程很简单基本能保证不踩漂移的坑任何模型配置变更必须同时提交代码和 Migration 文件。代码评审时Migration 文件和模型配置一起看。不允许任何人直接登录数据库改表结构所有变更走部署脚本。每次发布前在测试环境执行一次dotnet ef migrations list确认待应用的迁移符合预期。这套流程看起来很基础但真做到位的团队不多。多数漂移问题其实都是流程问题而不是技术问题。另外Migrations/AppDbContextModelSnapshot.cs这个文件是 EF 判断模型变化的基准别手改它让dotnet ef migrations add自己生成否则下次迁移时对比基准就乱了。4.2 慢查询排查先看生成的 SQL模型优化的收益最终要靠 SQL 质量来验证。排查性能问题第一步永远是“看 EF 生成的 SQL”否则你就是瞎猜。最简单的办法是打开日志optionsBuilder.LogTo(Console.WriteLine, LogLevel.Information) .EnableSensitiveDataLogging();Info 级别会打印 SQL 语句EnableSensitiveDataLogging会把参数值也带出来方便定位具体请求。注意这个开关在生产要慎开因为参数值可能包含个人数据。更专业一点实现IDbCommandInterceptor对每条命令记录耗时、参数、SQL从 EF Core 5 开始这就是官方推荐的做法比 LogTo 更适合做监控和告警。看 SQL 时重点看三件事有没有 Table Scan 或 Index Scan有则索引问题JOIN 数量是否异常膨胀有则可能是Include过多或缺少拆分条件是否被推到数据库执行如果WHERE后面空着说明查询被拖到客户端过滤了。客户端过滤是最隐蔽的坑我讲一个亲身案例团队有人在仓储层写了个FuncOrder, bool的参数查订单时传入判断方法结果 EF Core 无法把方法翻译成 SQL就把整张表拉到内存里过滤。单表几百万行线上直接卡死。换成ExpressionFuncOrder, bool之后EF Core 才把条件正确翻译进 SQL。这种问题靠日志一眼就能看出来SQL 里没有 WHERE 条件但结果集符合业务因为过滤发生在内存里。排查慢查询的流程我一般是这样先打开日志找到对应请求的 SQL把 SQL 复制到数据库工具看执行计划接着看有没有 Table Scan、是否走索引、Join 是否失控如果 SQL 本身跨了好几个表再看对应的 LINQ 是不是有Include过载或者 N1 循环。这个流程一步步下来绝大多数模型优化的性能问题都能定位到根因而不是靠猜。4.3 避坑速查表与个人心得把高频踩坑场景整理成一个速查表方便环境验证和排障也方便团队新人快速建立对 EF Core 模型优化的直觉问题场景现象建议decimal 精度丢失金额、税率计算偏差显式HasPrecision别依赖默认N1 查询响应时间随数据量线性上涨关闭延迟加载审查循环导航访问Include 过多结果集行数爆炸AsSplitQuery()或投影裁剪首次请求特别慢冷启动第一笔请求卡顿dotnet ef dbcontext optimize生成编译模型客户端过滤慢查询但 SQL 查了全表检查Func是否写成Expression模型与库漂移启动时抛模型变更异常保证 Migration 与模型同步提交唯一键并发冲突偶发唯一键异常数据库唯一索引 业务幂等字符串 max 类型索引失效、排序慢固定长度用HasMaxLengthAsNoTracking 后保存失败SaveChanges没有更新不跟踪实体修改前先Attach多对多映射错误关联表多出冗余字段显式配置中间实体并加唯一复合索引表格之外还有几条我写了多年才会明白的心得。第一EF Core 不是 ORM 里的银弹它是 LINQ 到 SQL 的翻译器。你尊重它的翻译规则它回馈接近手写 SQL 的性能你硬要用对象思维让它把全表拉下来它绝不会拦你只是会在生产环境教育你。第二模型优化不是一次性工程实体一多、业务一变索引、投影、加载策略都得跟着调整。最好为模型配置建立定期审查机制比如每个迭代末抽查一遍新增查询生成的 SQL别等问题线上爆发了再回头查。第三很多问题在开发环境测不出来不是因为数据量不够而是因为开发环境的慢查询被本地网络和缓存掩盖了。想让团队真正在意模型优化第一步就是把日志和监控挂上让每个人都能看到自己写的 LINQ 翻译成了什么 SQL看到了自然就会克制。我在实际项目里的经验是把模型优化当作一个“约束自己”的过程。约束自己写显式配置、约束自己写投影查询、约束自己不在循环里访问导航属性。这些约束不复杂难的是每次写代码时都记得。等你形成肌肉记忆EF Core 的模型性能问题会少掉一大半剩下的部分再用日志、索引、拆分查询逐个定点解决也就没有想象中那么可怕了。