结论是多数情况下应绕开视图内子查询，改写为join或物化视图；因oracle谓词下推能力弱，多层嵌套易致全表扫描，explain plan中view+filter即表明外层条件未下推，主因包括in/rownum/函数、缺索引及类型不一致。
直接说结论：多数情况下，不是优化视图里的子查询，而是绕开它——把子查询逻辑外提、改写为join、或用物化视图固化结果。oracle对多层嵌套子查询的谓词下推能力很弱，尤其在视图定义里，很容易触发全表扫描。
为什么EXPLAIN PLAN里总看到VIEW + FILTER而不是ACCESS
这是最典型的信号：外层WHERE条件没进到子查询内部，优化器被迫先执行整个子查询（可能返回百万行），再在外层做filter过滤。根本原因常是视图定义中用了IN、ROWNUM、函数包裹分区键，或子查询本身没索引支撑。
- 用
DBMS_XPLAN.DISPLAY_CURSOR查真实执行计划，重点看PREDICATE列——如果写的是filter("T1"."ID"="T2"."ID")而非access("T1"."ID"="T2"."ID")，说明连接没走索引 - 检查子查询是否含
ORDER BY或ROWNUM：它们会强制物化中间结果，阻断谓词下推 - 确认子查询字段类型和主表字段严格一致——
VARCHAR2列和CHAR列比较会隐式转换，索引失效
用EXISTS替代IN，但必须配索引
IN在子查询返回大量值时，Oracle常转成NESTED LOOPS或HASH JOIN，但如果子查询表t2没在关联字段上建索引，就会扫全表。而EXISTS天然适合半连接，只要t2有索引，就能快速定位。
- 错写：
WHERE t1.id IN (SELECT id FROM t2 WHERE status = 'A') - 改写：
WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.id = t1.id AND t2.status = 'A') - 必须同步在
t2(id, status)上建复合索引，顺序不能颠倒
分区表上的子查询为何不裁剪？
视图里写WHERE SUBSTR(dt, 1, 6) = '202606'，哪怕dt是分区键，Oracle也认不出——函数破坏了分区键的原始值。执行计划显示PARTITION RANGE ALL，实际I/O却扫了全部分区。
- 正确做法：把分区逻辑提到视图外层，比如
SELECT * FROM my_view WHERE dt >= DATE '2026-06-01' AND dt - 避免在子查询里用
TO_CHAR(dt, 'YYYYMM')，改用TRUNC(dt, 'MM')（后者支持分区裁剪） - 用
DBMS_XPLAN.DISPLAY_CURSOR查Partition Id列，验证是否只访问目标分区
什么时候该放弃子查询，直接上物化视图
当子查询涉及多表聚合、计算列、且基础数据变更不频繁（比如每日批处理后更新），硬优化不如固化结果。物化视图能跳过所有子查询执行过程，直接查预计算结果。
- 创建时加
ENABLE QUERY REWRITE，让优化器自动重写原SQL走MV - 刷新策略选
ON DEMAND，配合DBMS_MVIEW.REFRESH定时调用 - 注意MV日志开销——如果基表DML频繁，MV维护成本可能反超收益
真正难的不是写出能跑的SQL，而是判断哪一层子查询值得优化、哪一层该砍掉重来。很多“慢视图”问题，根子不在SQL写法，而在数据模型设计时没预留聚合路径或分区边界。
