oracle ef core 8复杂join易致filter全表扫描，需禁用include改用显式join投影；nls参数必须设为binary否则order by失效索引；分页弃用skip/take改游标；务必select字段+asnotracking()。
Oracle复杂JOIN生成的SQL嵌套过深，执行计划显示FILTER而非INDEX RANGE SCAN
EF Core 8默认将多层Include或ThenInclude翻译为LEFT JOIN + 子查询嵌套，Oracle优化器常拒绝下推谓词，导致外层FILTER扫描大量中间结果。这不是LINQ写法问题，而是Oracle.EntityFrameworkCore提供器对复杂导航路径的SQL生成策略限制。
- 用
AsNoTracking()强制关闭变更跟踪——哪怕只读也要加，否则每行额外创建EntityEntry对象，内存开销翻倍 - 避免
Include(x => x.OrderItems).ThenInclude(y => y.Product)三级加载；改用显式Join投影：from o in ctx.Orders join oi in ctx.OrderItems on o.Id equals oi.OrderId join p in ctx.Products on oi.ProductId equals p.Id select new { o.Id, oi.Quantity, p.Name } - 检查生成SQL中是否含
NLSSORT或TO_CHAR——若有，说明NLS参数未对齐，见下节
ORDER BY字段被NLSSORT包裹，索引完全失效
EF Core 8连接Oracle时，若未在连接字符串中硬编码NLS_SORT=BINARY，OrderBy会自动包裹NLSSORT("name")，而你建的普通B-Tree索引对NLSSORT函数不可用，执行计划里必然出现FULL TABLE SCAN。
- 连接字符串必须包含：
;NLS_SORT=BINARY;NLS_COMP=LINGUISTIC;NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS' -
UseOracleSQLCompatibility("19")必须显式调用，否则旧版兼容逻辑可能插入TO_DATE隐式转换 - 若真需拼音排序（如中文姓名），不能依赖默认NLS，必须单独建函数索引：
CREATE INDEX idx_name_pinyin ON orders (NLSSORT(customer_name, 'NLS_SORT=SCHINESE_PINYIN_M'))，且查询时OrderBy要显式写成x => EF.Functions.NlsSort(x.CustomerName, "SCHINESE_PINYIN_M")
分页用Skip/Take导致全表扫描，尤其大数据量
Oracle对ROWNUM分页有天然缺陷：EF Core生成的嵌套SQL先取全部结果再WHERE ROWNUM ，优化器无法将<code>WHERE条件下推到内层索引扫描阶段。即使加了索引，执行计划仍显示VIEW节点包裹TABLE ACCESS FULL。
- 大数据量（单表>10万行）必须放弃
Skip/Take，改用游标分页：WHERE id > @lastId ORDER BY id LIMIT 50，前端传上一页最后ID而非页码 - 小数据量可保留
Skip/Take，但必须配合Select投影+AsNoTracking()，例如：ctx.Orders.Where(x => x.Status == "Shipped").AsNoTracking().Select(x => new { x.Id, x.OrderDate }).Skip(1000).Take(50) - 绝对不要在
OrderBy中用计算表达式，如OrderBy(x => x.CreatedAt.Date)——这会让CreatedAt字段上的索引失效
联合查询字段过多，网络和GC压力陡增
EF Core默认返回完整实体，但复杂JOIN结果往往只用其中3–5个字段。传输2MB原始数据、反序列化为对象、再被GC回收，比直接查100KB投影数据慢3倍以上。
- 永远用
Select明确指定字段，禁用ToList()加载实体：.Select(x => new { x.OrderId, x.CustomerName, x.ItemCount, x.TotalAmount }) - 若需复用DTO，定义强类型匿名类或record，避免
dynamic或object[]——后者失去编译期检查且序列化更慢 - 注意Oracle字段名大小写：实体属性用
[Column("CUSTOMER_NAME")]映射，否则Select投影字段名不匹配会报ORA-00904: invalid identifier
NLS_SORT=LINGUISTIC下根本不会走那个索引——它连“相等比较”都变成了函数调用。这点在EF日志里看SQL一眼就能确认，但很多人直接跳过日志，埋头调优执行计划。
