Entity Framework Core生成的查询是否始终性能最优？求相关反例

首先给出明确结论：Entity Framework Core（以下简称EF Core）永远不会保证生成性能最优的SQL查询，它的SQL生成逻辑是通用场景下的权衡，在很多特定业务场景下，生成的语句执行效率远低于手写优化的原生SQL，常见的实际反例如下：

• 关联查询的N+1问题：在涉及多层嵌套关联、关联集合带过滤条件的查询场景下，即使用户显式使用了Include()预加载配置，部分版本的EF Core仍会生成N+1查询：先查一次主表得到N条主数据，再循环N次给每条主数据单独生成查询子表的语句。这类场景下手写原生SQL可以通过一次多表JOIN加条件过滤直接返回所有结果，当主表数据量超过千条时，查询耗时差距可达10倍以上。
• 复杂聚合的冗余子查询问题：当LINQ语句包含多层分组、多条件Distinct计数、多维度条件求和这类逻辑时，EF Core经常会生成2~3层的嵌套子查询，把本来可以在一次表扫描中完成的聚合逻辑拆成多次重复扫描同一张表。举个典型场景：统计每个文章分类下，同时带「原创」「技术」「2024年发布」三个标签的文章数量，EF Core生成的SQL会把文章表、标签关联表重复JOIN三次分别做条件过滤，而手写原生SQL可以通过一次JOIN搭配CASE WHEN条件聚合完成计算，磁盘IO量直接降到原生成语句的1/3，执行效率提升数倍。
• 宽表查询的无效字段拉取问题：如果实体类映射了包含大文本、二进制存储字段的宽表，只要LINQ语句中没有显式通过Select()指定返回字段，EF Core会默认生成SELECT *拉取所有字段（包括单条几MB的二进制、长文本内容），带来极大的网络传输和内存开销。哪怕显式写了字段投影，在涉及临时表、中间结果投影的复杂查询中，部分版本EF Core仍会将全字段塞入中间表查询逻辑，产生不必要的性能损耗。这类场景下手写SQL可以精准只返回需要的字段，大宽表场景下性能差距非常明显。
• 批量写操作的逐行生成问题：EF Core原生的SaveChanges()方法在处理批量更新、批量删除操作时，会为每一条变更数据单独生成一条UPDATE/DELETE语句，和数据库做N次网络往返。如果一次提交上千条变更，就会生成上千条独立执行的写语句，而手写原生SQL可以通过一条带WHERE条件的批量UPDATE/DELETE语句完成所有操作，性能差距可达上百倍。
• 特殊数据场景下的执行计划走偏问题：EF Core生成SQL时不会主动添加数据库层面的查询提示（比如强制命中指定索引、调整锁粒度、指定关联顺序），当表中数据分布存在倾斜（比如某个过滤条件的选择率极低，数据库优化器误判走全表扫描）时，EF Core生成的通用SQL会命中差的执行计划，这类场景在单表数据量过百万时非常常见，手写SQL可以通过调整语句顺序、增加查询提示主动命中最优索引，性能差距可达几十倍。

注：上述问题不代表EF Core不适合生产使用，绝大多数常规CRUD场景下，EF Core生成的SQL性能完全可以满足业务需求。遇到性能瓶颈时，可以先通过EF Core的日志捕获实际生成的SQL做针对性分析，确属生成语句冗余的场景，再用原生SQL替换即可。

内容的提问来源于stack exchange，提问作者DooDoo