EF Core Where子句使用预定义Expression时查询生成耗时过长

这是EF Core 5.0及更早版本存在的查询编译缓存机制缺陷，所有额外耗时都产生在EF Core端的重复查询编译流程，和数据库执行无关：

• 内联编写Where的lambda条件时，编译器生成的是固定结构的表达式实例，EF Core第一次执行完成查询翻译后，会将翻译结果存入全局查询缓存，后续执行直接命中缓存，跳过表达式遍历、映射校验、SQL生成等所有编译步骤，因此总耗时仅2秒。
• 当你把筛选逻辑预先定义为独立的Expression<Func<Entity, bool>>变量时，旧版本EF Core计算查询缓存键的逻辑存在漏洞，会把这个外部声明的表达式实例判定为「动态可变表达式」，无法命中已有的编译缓存，每次执行都会从头跑完整的查询编译流程：包括全量递归遍历表达式树、校验实体所有字段的映射配置、检查所有关联导航属性的元数据、生成SQL语法树、做参数合法性校验。如果你的实体配置了较多导航属性、值转换器或者复杂映射，这个递归遍历的耗时会呈指数级上涨，最终出现耗时从2秒暴涨到2分钟的情况。

你只需要把预定义的筛选表达式提取为类的静态只读字段即可：

private static readonly Expression<Func<Entity, bool>> FixedFilter = x => x.Field == "some value";

将这个静态表达式传入.Where()执行后，耗时会立刻回落到和内联写法一致的水平。原因是静态表达式不会被旧版EF Core的缓存判定逻辑识别为可变实例，可以正常命中查询编译缓存。

这个缓存判定的缺陷在EF Core 6.0及以上版本已经被官方修复，新版本优化了外部传入表达式的缓存键计算逻辑，不会再对独立声明的无闭包表达式做无意义的全量元数据遍历。

你观察到两种写法最终生成的SQL完全一致是正常现象——两种写法的表达式语义没有任何区别，性能差完全来自EF Core翻译前的重复无效计算。

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