Oracle视图中多层子查询导致全表扫描，因谓词下推能力弱，外层条件无法进入子查询；应将分区键条件提至视图调用处、避免ROWNUM/ORDER BY、统一字段类型、IN改EXISTS并建(id,status)复合索引。
视图里子查询导致全表扫描，怎么破？
直接结论：Oracle对视图定义中的多层子查询谓词下推能力很弱，外层WHERE条件大概率进不去子查询内部。执行计划里一看到VIEW节点配FILTER（而不是ACCESS），基本就坐实了——它先算完子查询所有结果，再在外层过滤。
常见错误现象：
- EXPLAIN PLAN显示
PARTITION RANGE ALL，但实际只查某个月数据 -
TABLE ACCESS FULL紧跟在IN-LIST ITERATOR后面 - Cardinality预估10行，实际返回几十万行
实操建议：
- 把分区键逻辑提到视图调用处：
SELECT * FROM my_view WHERE dt >= DATE '2026-11-01'，而不是在视图里写WHERE SUBSTR(dt, 1, 6) = '202611' - 禁用
ROWNUM和ORDER BY——它们强制物化，阻断下推 - 检查字段类型是否一致：
VARCHAR2列和CHAR列比较会触发隐式转换，索引失效
IN还是EXISTS？选错性能差6倍
当子查询返回大量值（比如>500行），IN极易引发全表扫描；而EXISTS只要命中第一条就退出，天然适合半连接场景。
典型错误写法：
WHERE t1.id IN (SELECT id FROM t2 WHERE status = 'A')
问题在于：如果t2没在(id, status)上建复合索引，或顺序颠倒，IN就会扫全表。
实操建议：
- 改写为
EXISTS：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)，顺序不能反 - 若子查询结果固定且小（IN，但得用绑定变量避免硬解析
WITH子句真能提速？别被语法糖骗了
在Oracle 21c中，WITH子句不是自动加速器。它只在中间结果集被引用≥2次时才可能节省重复计算；否则就是语法糖，甚至因强制物化变慢。
验证方式很简单：查V$SQL_PLAN，看是否有LOAD AS SELECT操作符，以及COST是否明显升高。
实操建议：
- 需要复用时，加提示：
WITH sales AS (SELECT /*+ MATERIALIZE NO_MERGE */ ...) - 只想让优化器内联展开，不物化：
WITH cust AS (SELECT /*+ INLINE */ ...) - 涉及
JSON_VALUE或VECTOR_DISTANCE等新函数时，MATERIALIZE可能报ORA-30926，此时只能用INLINE - 所有基表必须跑过
DBMS_STATS.GATHER_TABLE_STATS，否则优化器无法估算物化收益
什么时候该放弃优化，直接换方案？
当子查询涉及多表聚合、窗口函数、复杂计算列，且基础数据变更不频繁（如T+1批处理更新），继续调优收益极低。硬扛不如换路子。
实操建议：
- 用物化视图固化结果：
CREATE MATERIALIZED VIEW mv_sales_summary REFRESH COMPLETE ON DEMAND ENABLE QUERY REWRITE AS ... - 关键要加
ENABLE QUERY REWRITE，让优化器自动把原查询重写成查MV - 如果视图只是报表用途，且用户能接受分钟级延迟，物化视图比任何子查询优化都可靠
- 临时表方案慎用：
CREATE GLOBAL TEMPORARY TABLE需手动管理生命周期，且无法被查询重写捕获
最常被忽略的一点：所有这些优化的前提，是统计信息必须最新。哪怕你把SQL改得再漂亮，DBMS_STATS.GATHER_TABLE_STATS没跑过，优化器照样瞎猜。
