EF Core连Oracle查询慢的主因是客户端求值，即未翻译的LINQ表达式导致全表拉取后内存过滤；可通过日志警告、启用ClientEvalWarning异常、检查函数翻译、大小写一致性、v$sql执行计划等定位并解决。
EF Core查Oracle时SQL特别慢，先看是不是客户端求值
绝大多数ef core连oracle慢的问题，根源是查询在客户端执行了——也就是tolist()之前的部分逻辑没转成sql，而是把整张表拉到内存里再过滤。oracle端只看到一个没条件的select *，数据一多就卡死。
怎么确认？打开EF Core日志，找Microsoft.EntityFrameworkCore.Query级别日志，如果看到类似Client evaluation failed或Warning: The LINQ expression could not be translated，就是它了。
- 常见触发点：
.Any(x => x.Name.Contains("abc"))中Contains用的是.NET字符串方法（非EF.Functions.Contains），Oracle Provider不支持翻译 - 自定义函数、
DateTime.Now.AddDays(7)这种计算，除非显式用EF.Functions或DateTimeOffset.UtcNow，否则大概率客户端求值 - 投影到匿名类型或DTO时用了
new { x.Prop.ToUpper() }——ToUpper()在Oracle里得靠EF.Functions.Upper(x.Prop)
禁用客户端求值：不是开关，是编译期拦截
DbContextOptionsBuilder里设ConfigureWarnings(w => w.Throw(RelationalEventId.QueryClientEvaluationWarning))，能让客户端求值直接抛异常，而不是默默降级执行。这是最有效的“禁用”方式——不是阻止运行，而是让问题暴露在开发阶段。
注意：这个配置对Oracle Provider有效，但某些旧版Oracle.EntityFrameworkCore（比如5.x）可能不完全识别该警告ID，建议升级到6.0+并用RelationalEventId.ClientEvalWarning（具体ID名以你引用的Provider版本文档为准）。
- 别用
AsEnumerable().Where(...)来“绕过”翻译失败——这等于主动开启客户端求值 - 如果必须用复杂逻辑，拆成两步：先用可翻译的条件
Where从DB捞出子集，再AsEnumerable()做后续处理 - 检查
IQueryable变量是否被意外赋值为IEnumerable（比如方法返回类型写错），这是静默降级的高发场景
Oracle特有翻译陷阱：函数名和大小写敏感
EF Core Oracle Provider对函数翻译很严格，比如string.Contains默认不翻译，但EF.Functions.InStr或EF.Functions.Like可以；DateTime.Date不支持，得用EF.Functions.Trunc。
更隐蔽的是大小写：Oracle默认对象名大写，但EF Core生成的列名若带小写字母（比如用[Column("order_date")]），而你的查询又写了x.OrderDate（PascalCase），Provider可能因匹配失败放弃翻译，退化为客户端求值。
- 统一用
[Column("ORDER_DATE")]并保持实体属性名与数据库列名大小写一致，或启用UseOracleSQLCompatibility(OracleSQLCompatibility.Full) -
OrderBy(x => x.Name)在含中文或特殊字符时可能触发NLS_SORT相关隐式转换，导致索引失效——加EF.Functions.NLSSort(x.Name, "BINARY_CI")明确指定排序规则 - 避免
DateTimeKind混用：DateTime.Now（本地时区）和DateTime.UtcNow（UTC）在Oracle里对应DATE和TIMESTAMP WITH TIME ZONE，类型不匹配会强制转换，拖慢查询
验证SQL是否真由Oracle执行：别信日志，要看v$sql
EF Core日志里打印的SQL，只是它“打算发”的语句，实际到Oracle执行的可能是另一回事——比如绑定参数被Oracle优化器重写、隐式类型转换插入、甚至因统计信息过期走了全表扫描。
最可靠的方式是登录Oracle服务器，查v$sql视图，用sql_text like '%your_table_name%'定位真实执行的语句，再用EXPLAIN PLAN FOR ...看执行计划。
- 重点关注
access_predicates和filter_predicates字段：前者是走索引的条件，后者是索引后在内存里过滤的条件——如果大量逻辑出现在filter_predicates，说明索引没用好或条件不可下推 - 留意
cardinality预估行数是否严重偏离实际，这往往意味着统计信息陈旧，需手动DBMS_STATS.GATHER_TABLE_STATS - EF Core生成的SQL常带
FETCH FIRST @p0 ROWS ONLY，Oracle 12c+支持，但老版本会降级为ROWNUM嵌套，且无法下推WHERE条件——确认你的Oracle版本和Provider是否匹配
真正难调的从来不是LINQ怎么写，而是哪段逻辑被悄悄留在了C#内存里，或者哪条看似简单的Where触发了Oracle端的隐式转换。盯住v$sql里的filter_predicates，比反复改C#代码管用得多。
