EF Core对Oracle生成嵌套子查询的根本原因是Oracle不支持OFFSET/FETCH分页，被迫采用ROWNUM嵌套模式；配合AsNoTracking、Select投影、游标分页或SqlQueryRaw可有效规避。
EF Core对Oracle生成嵌套子查询的根本原因
不是EF Core“故意写复杂”，而是它在Oracle上无法像SQL Server那样直接用OFFSET/FETCH实现分页，只能退回到ROWNUM嵌套模式。这个模式天然要求把原始查询包进一层子查询，再在外层加WHERE ROWNUM ——而一旦你链式调用Skip()和Take()、又带OrderBy()和Where()，EF Core就得层层嵌套：排序子查询 → 分页子查询 → 过滤子查询 → 投影子查询。最终生成的SQL可能套4～5层SELECT ... FROM (SELECT ... FROM (...))。
哪些LINQ操作会显著加剧子查询层数
以下操作在Oracle Provider中极易触发额外嵌套，尤其组合使用时：
-
OrderBy().ThenBy()：每多一个排序字段，EF Core常生成独立NLSSORT包裹，而每个NLSSORT都可能迫使优化器放弃索引，进而让外层ROWNUM必须基于全结果集裁剪 -
Include()+ThenInclude()：导航属性加载会强制生成LEFT JOIN，但Oracle Provider为保语义正确，常把JOIN逻辑塞进内层子查询，导致外层ROWNUM作用域扩大 -
Select(x => new { x.Id, x.Name })配合Skip/Take：EF Core 8之前版本会先投影再分页，即SELECT ... FROM (SELECT id,name FROM ...) WHERE ROWNUM ，而非更优的SELECT * FROM (SELECT ..., ROWNUM r FROM (...)) WHERE r > 5 -
Count()与分页共存：ToListAsync()前若调用了CountAsync()，EF Core默认不复用查询计划，两次生成结构相似但独立的嵌套SQL
绕过子查询膨胀的三个实操路径
不用重写全部DAL，优先从这三处切入：
- 对纯读取场景，强制用
AsNoTracking()：减少变更跟踪开销，让EF Core更倾向生成扁平化SQL；配合Select()只取必要字段，可避免因实体映射复杂度引发的额外包装 - 分页改用游标（keyset）而非偏移量：用
WHERE id > @lastId ORDER BY id LIMIT 10替代Skip(1000).Take(10)，彻底避开ROWNUM嵌套——需业务接受“不能跳页” - 关键报表类查询，直接切到
SqlQueryRaw：EF Core 8支持非实体类型映射，例如() context.Database.SqlQueryRaw，完全跳过LINQ翻译链("SELECT o.status, COUNT(*), SUM(o.amount) FROM orders o GROUP BY o.status")
最容易被忽略的隐性放大点
很多人查执行计划只看顶层ROWNUM，却漏掉两处关键细节：
- NLS参数污染：
NLS_SORT或NLS_COMP设为LINGUISTIC时，ORDER BY name会被自动转成ORDER BY NLSSORT(name)，而NLSSORT函数索引必须显式创建，否则就是全表扫描+嵌套排序 - 统计信息陈旧：Oracle CBO依赖表/索引统计信息做成本估算，若未定期运行
DBMS_STATS.GATHER_TABLE_STATS，优化器可能误判嵌套子查询比HASH JOIN更便宜，主动选择更深嵌套路径
