oracle 19c中带子查询的视图无法自动优化，尤其含聚合、函数、null敏感逻辑或多表关联时，优化器常跳过解嵌套致n次重复执行，须手动改写并严控null语义、group by完整性及物化视图限制。
Oracle 19c 中带子查询的视图无法靠优化器自动“变快”——尤其当子查询含聚合、函数、NULL 敏感逻辑或跨多表关联时，优化器大概率跳过解嵌套，导致 N 次重复执行。必须手动干预改写，且关键点不在“怎么写”，而在“为什么不能信默认行为”。
标量子查询不自动解嵌套的典型场景
Oracle 19c 默认开启 _optimizer_unnest_scalar_sq=TRUE，但以下情况会让它直接放弃转换，退化为 FILTER 操作（每行触发一次子查询）：
- 子查询 SELECT 列用了
NVL、COALESCE或CASE包裹 - 子查询 WHERE 条件含函数，如
TRIM(d.deptno)，破坏索引可用性 - 主表连接列（如
e.deptno）存在大量 NULL，且子查询未显式处理 NULL 分支 - 子查询含
DISTINCT、ROWNUM或非确定性函数（如SYS_GUID()）
此时强制设 _optimizer_unnest_scalar_sq=FALSE 反而更可控：避免生成“半解嵌套+FILTER”的混合计划，逼你走明确的 JOIN 路径。
LEFT JOIN 改写时 GROUP BY 容易漏掉的两处
把 (SELECT MAX(e.sal) FROM emp e WHERE e.deptno = d.deptno) 改成 JOIN，常见错误不是语法错，而是语义错：
- 内联视图里漏
GROUP BY department_id→ 导致结果集膨胀，主表一行变多行，后续聚合报ORA-00937: not a single-group group function - 外层主查询漏
GROUP BY→ 即使内联视图正确聚合，主查询选了d.department_name却没在GROUP BY列表中，同样触发ORA-00937 -
NVL放错位置：写在内联视图里（SELECT deptno, NVL(MAX(sal), 0)）会让空部门返回 0；而原标量子查询返回 NULL，业务逻辑可能断裂
正确写法是先内聚再关联：
SELECT d.deptno, d.dname, e.max_sal<br>FROM dept d<br>LEFT JOIN (<br> SELECT deptno, MAX(sal) AS max_sal<br> FROM emp<br> GROUP BY deptno<br>) e ON d.deptno = e.deptno
物化视图 + 子查询的硬限制与绕行路径
只要视图定义里出现 EXISTS、NOT EXISTS、IN、ANY、ALL 或任何非关联子查询，DBMS_MVIEW.EXPLAIN_MVIEW 必返回 fastrefreshable = FALSE ——这不是配置问题，是 Oracle 内核级禁止。
- 用
INNER JOIN替代EXISTS：最安全，但要求两个基表都有完整物化视图日志（WITH PRIMARY KEY, SEQUENCE(...)） - 用
UNION ALL拆NOT EXISTS：不能直接用LEFT JOIN ... IS NULL（不支持 FAST），必须拆成“匹配部分 + 不匹配部分”，后者需依赖单表主键关联 -
IN (subquery)若子查询只查单列主键（如SELECT deptno FROM dept WHERE loc = 'DALLAS'），可转为INNER JOIN；若含聚合或多列，必须在子查询目标表上建日志并显式覆盖所有被引用字段（SEQUENCE(deptno, loc)）
真正难的不是写出等价 SQL，而是确认改写后 NULL 行为、空集合语义、并发一致性是否和原逻辑完全对齐——这些细节在测试数据里往往不暴露，上线后才出问题。
