根本原因是oracle优化器对rownum分页的天然限制：外层rownum无法下推至索引扫描阶段，必须先取全部结果再裁剪；叠加order by字段无索引或被nlssort隐式包裹时，极易触发全表扫描。
EF Core 对 Oracle 生成的 SQL 效率低，根本原因不是 EF Core 写得差，而是它默认的分页和排序机制撞上了 Oracle 优化器的几个硬限制——尤其是 ROWNUM 嵌套、NLSSORT 隐式包裹、以及缺失索引提示这三者叠加时，执行计划里几乎必出 full table scan。
为什么 Skip/Take 在 Oracle 上会触发全表扫描
EF Core 的 Skip()/Take() 在 Oracle Provider 下默认翻译为两层子查询：外层用 ROWNUM 截断，内层先 <code>ORDER BY。但 Oracle 无法把 ROWNUM 条件下推到索引扫描阶段，必须先把全部排序结果算出来，再裁剪——数据量一过百万，I/O 和内存压力就陡增。
常见错误现象：
- 执行计划中出现
VIEW+SORT ORDER BY+COUNT STOPKEY，且ROWS列远大于实际返回行数 - 即使
ORDER BY字段有索引，执行计划仍显示INDEX FULL SCAN或TABLE ACCESS FULL
关键原因：
-
ORDER BY name实际被 Oracle Provider 自动转成ORDER BY NLSSORT(name, 'NLS_SORT=BINARY')（受连接字符串或会话级NLS_SORT影响） - 而你建的普通索引对
NLSSORT()函数无效，必须显式建函数索引：CREATE INDEX idx_orders_name_binary ON orders (NLSSORT(name, 'NLS_SORT=BINARY'))
如何确认是不是 NLS 参数惹的祸
直接查当前会话的 NLS 设置比看文档更快：
SELECT * FROM NLS_SESSION_PARAMETERS WHERE PARAMETER IN ('NLS_SORT', 'NLS_COMP');
如果返回 NLS_SORT = 'LINGUISTIC' 或 NLS_COMP = 'ANSI'，基本可以锁定问题——EF Core 生成的排序语句会被强制套上 NLSSORT()，导致索引失效。
临时验证方法（在 SQL*Plus 或 SQL Developer 中执行）：
- 手动运行 EF Core 日志里捕获到的原始 SQL，观察执行计划
- 再运行等价的“去 NLS 化”版本：
SELECT * FROM (SELECT /*+ INDEX(t idx_name_binary) */ ..., ROWNUM rnum FROM (SELECT ... ORDER BY name) t) WHERE rnum > 10 AND rnum - 对比两次的
Cost和Bytes—— 差异超过 10 倍，就是 NLS 拖累
绕过 ROWNUM 分页的三个实操选择
不是所有场景都适合改写 SQL，但以下方案可落地：
- 小数据量（AsNoTracking() +
Select()投影，减少内存拷贝开销，但不解决分页本身 - 中等数据量（5k–100k）：在 DbContext 构造时显式设置会话级 NLS：
connection.Execute("ALTER SESSION SET NLS_SORT = 'BINARY'"); - 大数据量（> 100k）：放弃
Skip/Take，改用游标分页（keyset pagination），例如按id DESC+WHERE id ，配合覆盖索引 <code>CREATE INDEX idx_orders_id_desc ON orders (id DESC)
注意：Oracle 12c+ 支持 OFFSET/FETCH，但 EF Core Oracle Provider（如 Oracle.EntityFrameworkCore 7.x）默认仍走 ROWNUM 路径，需手动切换 Provider 或用 FromSqlRaw 强制。
最容易被忽略的索引陷阱
很多人建了索引还慢，是因为只建了字段索引，没管排序方向和函数封装：
-
ORDER BY created_at DESC需要反向索引：CREATE INDEX idx_orders_created_desc ON orders (created_at DESC)，普通升序索引效果差 -
WHERE status = 'paid' ORDER BY id这种组合，单列索引无效，得建联合索引且顺序匹配：CREATE INDEX idx_orders_status_id ON orders (status, id) - 用了
AsNoTracking()却忘了Select()投影——EF Core 仍会加载整行字段，网络和序列化开销照旧
真正卡住性能的，往往不是 EF Core 本身，而是 Oracle 会话参数、索引定义、以及分页模型三者之间那几毫米的错位。
