子查询常是性能隐患而非优化手段，尤其pl/sql中多层嵌套易致全表扫描、中间结果物化、谓词无法下推；explain plan显示view+filter即为典型信号，主因包括in/not in/rownum/order by强制物化、类型不匹配引发隐式转换、分区键上用函数等；应优先用带索引的exists替代in，并将分区裁剪逻辑外提至外层查询。
多数情况下，子查询不是用来“优化”复杂逻辑的，而是需要被重写或绕开的性能隐患点——尤其在PL/SQL中嵌套多层子查询，极易触发全表扫描、中间结果物化、谓词无法下推等问题。
为什么EXPLAIN PLAN里总看到VIEW + FILTER
这是最直接的信号：外层WHERE条件没进到子查询内部。Oracle被迫先执行整个子查询（可能返回几十万行），再在外层做filter过滤。常见诱因包括：
-
IN、NOT IN、ROWNUM、ORDER BY出现在子查询中——它们会强制物化中间结果，阻断谓词下推 - 子查询字段类型和主表不一致，比如
VARCHAR2列与CHAR列比较，引发隐式转换，索引失效 - 分区键上用了函数，如
SUBSTR(dt, 1, 6)，导致PARTITION RANGE ALL，实际扫了全部分区
用EXISTS替代IN但必须配索引
IN在子查询返回大量值时，Oracle常转成HASH JOIN或NESTED LOOPS；若子查询表无索引支撑，就会全表扫描主表。而EXISTS天然适合半连接，只要子表有索引就能快速定位。
错写：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')
必须同步建复合索引：CREATE INDEX idx_t2_id_status ON t2(id, status)，顺序不能颠倒
分区表上的子查询必须把裁剪逻辑提到外层
视图定义里写WHERE SUBSTR(dt, 1, 6) = '202606'，哪怕dt是分区键，Oracle也认不出——函数破坏了原始值。执行计划显示PARTITION RANGE ALL，I/O却扫了全部分区。
正确做法是把分区逻辑外提：
- 视图只定义基础查询：
CREATE VIEW v AS SELECT * FROM partitioned_table - 调用时加真实条件：
SELECT * FROM v 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命中物化视图 - 确保统计信息最新：
DBMS_STATS.GATHER_TABLE_STATS作用于物化视图本身 - 如果基础表更新频繁，考虑
ON COMMIT刷新，否则用DBMS_MVIEW.REFRESH定时刷新
真正容易被忽略的是：物化视图不是建完就生效的，QUERY REWRITE需数据库级参数QUERY_REWRITE_ENABLED=TRUE，且用户要有QUERY REWRITE权限。
