Oracle 19c视图中相关子查询不缓存，每次调用均内联展开，导致ETL性能骤降；其根本原因是优化器常退化为嵌套循环，引发海量重复扫描，应优先改写为LEFT JOIN、预聚合或物化视图等高效模式。
Oracle 19c 中视图里的子查询不会缓存，每次调用都会内联展开——ETL跑得慢，八成卡在这儿。
为什么相关子查询在ETL里特别伤性能
数据仓库ETL通常是批量执行（比如每天凌晨跑一次），而视图中嵌套的相关子查询（如 WHERE u.id IN (SELECT user_id FROM log WHERE dt = u.dt)）会被优化器原样展开。Oracle 19c 虽有自适应执行计划，但面对这类模式仍常退化为嵌套循环：外层表 10 万行 × 子查询扫描 500 行 = 5000 万行扫描。更麻烦的是，EXPLAIN PLAN 里若看到 type=ALL 或 rows 列远超实际值，基本可以确认是子查询拖了后腿。
常见诱因包括：
-
SUBSTR(dt, 1, 6)这类函数写法阻断分区裁剪，哪怕表已按dt分区，也会触发PARTITION RANGE ALL -
NOT IN子查询未处理 NULL，导致结果为空或逻辑错误，且无法走索引 - 标量子查询（如
(SELECT COUNT(*) FROM detail WHERE master_id = m.id)）强制逐行执行，无法并行
用 LEFT JOIN IS NULL 替代 NOT IN 子查询
这是 ETL SQL 中最该优先改写的模式。原始写法 WHERE order_id NOT IN (SELECT order_id FROM returns WHERE return_date >= DATE '2026-09-01') 在 Oracle 19c 下极易引发全表扫描和临时磁盘排序。
正确做法是把过滤条件写进 ON 子句，并确保索引覆盖：
LEFT JOIN returns r ON o.order_id = r.order_id AND r.return_date >= DATE '2026-09-01' WHERE r.order_id IS NULL
关键点：
- 必须把
return_date >= ...放在ON里，否则WHERE r.order_id IS NULL会变成 INNER JOIN 语义 - 索引需为复合索引：
CREATE INDEX idx_returns_oid_dt ON returns(order_id, return_date)，单列索引无效 - 该写法在 Oracle 19c 中可被识别为哈希连接（
HASH JOIN RIGHT ANTI），避免逐行判断
用预聚合子查询替代 EXISTS/标量子查询
ETL 中频繁出现的标记类逻辑，如 (SELECT 1 FROM sales_detail d WHERE d.order_id = o.order_id AND d.product_type = 'premium')，会让优化器无法下推 product_type = 'premium'，常导致全表扫描。
改成先聚合再关联：
SELECT o.order_id,
COALESCE(p.has_premium, 0) AS has_premium
FROM orders o
LEFT JOIN (
SELECT order_id, 1 AS has_premium
FROM sales_detail
WHERE product_type = 'premium'
GROUP BY order_id
) p ON o.order_id = p.order_id
优势明显：
- 子查询带
WHERE条件，更容易触发索引范围扫描 - 如果
sales_detail是按order_id或product_type分区，分区裁剪能生效 - Oracle 19c 的物化 CTE（
WITH x AS (MATERIALIZED) SELECT ...）可进一步固化中间结果，避免重复计算
物化视图比普通视图更适合高频ETL依赖
普通视图只是 SQL 文本别名，每次引用都重解析、重展开；而物化视图（MATERIALIZED VIEW）是真实存储的数据快照，在 Oracle 19c 中支持快速刷新（ON COMMIT 或 DBMS_MVIEW.REFRESH）和查询重写（QUERY REWRITE）。
适合场景：
- ETL 中反复调用的聚合结果（如每日用户活跃统计）
- 跨大表 JOIN 后的宽表，且下游多个任务依赖同一输出
- 需要稳定执行计划，避免统计信息波动影响性能
注意两点：
- 启用查询重写需设置
ALTER SESSION SET QUERY_REWRITE_ENABLED = TRUE，且 MV 必须处于BUILD IMMEDIATE REFRESH FAST ON COMMIT状态 - 物化视图日志（
CREATE MATERIALIZED VIEW LOG ON table_name）必须存在，否则无法快速刷新
真正容易被忽略的是：物化视图的刷新锁和主表 DML 冲突。ETL 批量写入期间若同时刷新 MV，可能触发长时间等待 —— 建议把 MV 刷新安排在 ETL 主体完成后单独串行执行，而不是混在 INSERT 语句里。
