深层嵌套子查询在oracle 19c中极易导致执行计划退化，表现为depended subquery或连续view节点、filter而非access谓词、cardinality严重失真；应通过dbms_xplan.display_cursor确认，用qb_name锚定查询块配合unnest/no_unnest提示优化，并将标量子查询重写为join或改用exists。
深层嵌套子查询在 Oracle 19c 中极大概率导致执行计划退化，不是慢一点，而是直接触发全表扫描或重复执行——只要执行计划里出现 DEPENDENT SUBQUERY 或连续多层 VIEW 节点，就说明优化器已放弃下推谓词，你写的 SQL 能跑通，但性能不可控。
怎么一眼确认是深层嵌套惹的祸
别猜，直接看执行计划：
- 用
DBMS_XPLAN.DISPLAY_CURSOR查真实执行计划（不是EXPLAIN PLAN FOR），重点盯Operation列是否密集出现VIEW+FILTER - 查
PREDICATE列：如果写的是filter("T1"."ID"="T2"."ID")而非access("T1"."ID"="T2"."ID")，说明连接没走索引，谓词被卡在外层 - 三层及以上嵌套（比如
WHERE x IN (SELECT ... WHERE y IN (SELECT ...))）基本无法下推，Cardinality预估常严重失真（预估 10 行，实际返回百万行）
UNNEST 和 NO_UNNEST 提示必须带 QB_NAME 才生效
在嵌套视图或子查询里写 /*+ INDEX(t1 idx_t1_id) */ 几乎无效——优化器展开视图后，原提示所在查询块已不存在。真正起作用的写法是锚定查询块名：
- 先用
DBMS_XPLAN.DISPLAY_CURSOR看执行计划里的Query Block Name（如SEL$2、SUBQ1） - 在外层加
/*+ QB_NAME(main) */，子查询里加/*+ QB_NAME(subq) */ - 再写提示：例如
/*+ UNNEST(@subq) */强制展开该子查询，或/*+ NO_UNNEST(@subq) */阻止它被错误合并 - 漏掉
@subq，提示就绑定到主查询块，对子查询毫无影响
标量子查询在 SELECT 列表里必须重写为 JOIN
SELECT name, (SELECT COUNT(*) FROM log l WHERE l.user_id = u.id) FROM users u 这类写法本质是隐式循环：users 表每扫一行，log 表就全表扫描一次。优化器不会自动把它转成 HASH JOIN，除非你手动拆解：
- 先聚合再关联：
SELECT u.name, COALESCE(l.cnt, 0) FROM users u LEFT JOIN (SELECT user_id, COUNT(*) cnt FROM log GROUP BY user_id) l ON u.id = l.user_id - 内层子查询必须含
GROUP BY，否则COUNT(*)会报ORA-00937 - 外层若还有
WHERE条件（如u.status = 'A'），要确保这个条件能下推到users表——否则LEFT JOIN后仍要 filter 百万行 - 如果只是判断“是否存在”，一律改用
EXISTS，它天然支持短路退出，且更容易走索引
分区键上别用函数，否则分区裁剪失效
视图里写 WHERE TO_CHAR(dt, 'YYYYMM') = '202606'，哪怕 dt 是分区键，执行计划也会显示 PARTITION RANGE ALL——Oracle 认不出这是分区裁剪逻辑。真正能裁剪的写法是：
- 用范围条件：
dt >= DATE '2026-06-01' AND dt - 用
TRUNC(dt, 'MM')替代TO_CHAR，前者支持分区裁剪，后者不支持 - 检查执行计划的
Partition Id列，确认只访问目标分区，而非全部 - 如果必须保留函数逻辑，建函数索引：
CREATE INDEX idx_dt_yyyymm ON t1(TO_CHAR(dt, 'YYYYMM'))，但注意这不能替代分区裁剪
最易被忽略的一点：嵌套层级越深，优化器越倾向于放弃索引选择，哪怕所有字段都有索引、统计信息最新——这不是 bug，是 CBO 在成本估算失真后的保守降级。与其反复调 Hint，不如从结构上拆解：用 WITH 分步固化中间结果，或把高频子查询物化为全局临时表并加索引。
