oracle 19c默认不展开含聚合、函数、null逻辑或嵌套视图的子查询，常退化为filter操作；必须用qb_name配合unnest(@name)手动干预，且需避免materialize冲突、确保统计信息准确。
Oracle 19c 默认不会对所有子查询做展开（UNNEST），尤其在含聚合、函数、NULL逻辑或嵌套视图时，优化器常退回到 FILTER 操作——这意味着外层每行都触发一次子查询执行，N 行就执行 N 次，性能直接崩盘。
什么时候必须手动干预 UNNEST？
不是所有子查询都能被自动展开。以下情况优化器大概率跳过 UNNEST，导致执行计划里出现 FILTER 或 NESTED LOOPS：
- 子查询里用了
MAX()、COUNT()、DISTINCT、ROWNUM等非确定性操作 - WHERE 条件中对关联列做了函数处理，比如
WHERE TRIM(d.deptno) = e.deptno，索引失效后优化器放弃展开 - 子查询返回 NULL 的语义敏感（如用
NVL((SELECT ...), 0)），优化器为保语义安全而禁用 UNNEST - 子查询嵌套了不可合并的视图（如含
ROWNUM ），优化器无法拉平结构
用 UNNEST 提示强制展开，但得配 QB_NAME
单写 /*+ UNNEST */ 很可能无效——Oracle 19c 对多层嵌套子查询需要明确作用域。正确做法是给子查询打标签，再在主查询中引用：
SELECT /*+ UNNEST(@subq) */ e.empno, e.ename FROM emp e WHERE e.salary > ( SELECT /*+ QB_NAME(subq) */ AVG(e2.salary) FROM emp e2 WHERE e2.deptno = e.deptno );
关键点：
-
QB_NAME必须写在子查询内部，且名称要和UNNEST(@...)中的一致 - 若子查询本身还嵌套了另一层子查询，需逐层命名，比如
@subq1、@subq2 - 不要在子查询里同时加
MATERIALIZE——它会阻止 UNNEST，两者互斥
展开失败时，NO_UNNEST 反而是更稳的选择
强行 UNNEST 可能引发笛卡尔积或数据膨胀（比如漏写 GROUP BY 导致 JOIN 后行数爆炸）。这时不如关掉自动展开，改用可控的内联视图重写：
- 先确认子查询是否真能独立执行：单独运行它，看是否走索引、是否返回合理行数
- 把子查询提前聚合好，例如
(SELECT deptno, MAX(salary) FROM emp GROUP BY deptno)，确保内层已去重/聚合 - 用
LEFT JOIN关联，且主查询的SELECT和GROUP BY必须严格对齐，否则报ORA-00937 - 原标量子查询里的
NVL(..., 0)要挪到外层 JOIN 后，别写进内联视图里——否则空部门会被错误补 0
最易被忽略的是：UNNEST 不是万能开关，它依赖统计信息新鲜度、索引可用性、以及子查询本身的确定性。哪怕加了提示，如果子查询里用了 SYS_GUID() 或未分析的表，优化器仍会静默忽略。动手前，先跑一遍 EXPLAIN PLAN FOR，盯住 OPERATION 列是否真出现了 NESTED LOOPS 或 HASH JOIN ——而不是只信提示写了没写。
