Oracle 19c中外连接执行计划异常主因是优化器被JOIN结构或统计信息误导；需重点检查Operation类型、driven表访问路径、access谓词完整性，并确保虚拟列等隐藏列统计信息已显式收集。
Oracle 19c 中外连接执行计划异常，八成不是 SQL 写错了，而是优化器被 JOIN 结构或统计信息“骗”了——尤其当出现全表扫描、基数估算崩坏（比如预估 1 行实际返回 10 万行）、或 FULL OUTER JOIN 结果缺失右表部分数据时，必须从执行计划底层动因切入。
怎么看执行计划里OUTER JOIN是否真走索引？
别只扫一眼 PLAN_TABLE_OUTPUT 里有没有 “INDEX” 字样。重点看三处：
- 操作 ID 对应的
Operation是否为HASH JOIN OUTER或NESTED LOOPS OUTER，而非HASH JOIN（那是内连接） - 若用了
NESTED LOOPS OUTER，确认其内部表（driven table）的访问路径是INDEX RANGE SCAN或INDEX UNIQUE SCAN，而不是TABLE ACCESS FULL - 检查
Predicate Information中的 access 谓词是否完整包含 JOIN 条件，例如access("A"."ID"="B"."A_ID"(+))—— 若这里漏了(+)或写成filter，说明优化器已降级为 FILTER 操作，索引基本失效
常见误判：看到 INDEX RANGE SCAN 就以为 OK，但若它出现在 FILTER 步骤下（非 access），只是用来做单表过滤，和 JOIN 无关。
为什么FULL OUTER JOIN结果少了一边？
这不是 bug，是 Oracle 对 FULL OUTER JOIN 的语义实现严格遵循“先左后右再合并”逻辑，但极易被子查询或聚合干扰。典型现象：右表有数据，结果里却没出现。
- 最常见原因：JOIN 条件中混用了聚合列（如
SUM(b)）且未在子查询中显式去重或对齐，导致优化器把右表子查询当作“不可扩展集合”，跳过补 NULL 逻辑 - 验证方法：把
FULL OUTER JOIN拆成两个LEFT JOIN+UNION ALL手动模拟，对比结果。若手动写法能出全，说明原写法触发了优化器路径限制 - 绕过方式：避免在
FULL OUTER JOIN右侧用带GROUP BY的子查询；改用 CTE 预计算并加唯一键约束，或改用UNION ALL+NOT EXISTS显式构造
注意：EXPLAIN PLAN 中若出现 UNION-ALL 嵌套在 VIEW 下，且第二分支含 HASH GROUP BY + HASH JOIN ANTI，基本就是这个模式在作祟。
统计信息缺失如何让OUTER JOIN变慢十倍？
外连接对统计信息比内连接更敏感——特别是虚拟列、隐藏列、JOIN 列的 NDV（distinct value count）和 null ratio。一旦失准，CBO 会错误选择驱动表，把大表当驱动表，引发海量嵌套循环或内存溢出。
- 虚拟列（如
name_upper AS (UPPER(name)) VIRTUAL）默认不收集统计信息，必须显式加method_opt => 'FOR ALL HIDDEN COLUMNS SIZE AUTO'参数调用DBMS_STATS.GATHER_TABLE_STATS - 检查
USER_TAB_COL_STATISTICS，确认 JOIN 列的NUM_DISTINCT和NUM_NULLS是否合理。若NUM_NULLS为 0 但实际大量为 NULL，CBO 会低估右表补 NULL 的开销 - 对
FULL OUTER JOIN，还要查USER_TAB_STATISTICS中NUM_ROWS是否同步更新——若右表刚批量插入但没收集统计信息，CBO 可能按旧行数估算，导致选错连接算法
一个容易被忽略的点：LEFT JOIN 中若右表有函数索引但列本身无直方图，CBO 无法判断该函数输出值的分布倾斜度，可能放弃使用该索引。
ORA-01417 报错时执行计划根本不会生成
遇到 ORA-01417: a table may be outer joined to at most one other table，不是执行计划异常，是 SQL 根本没进优化器阶段——解析器直接拒掉。此时 EXPLAIN PLAN 会失败，不是计划不准，是压根没计划。
- 典型结构：
FROM t1 LEFT JOIN t2 ON ... LEFT JOIN t3 ON ...，其中t2和t3都依赖t1，但彼此无关联。Oracle 认为t1被两个外连接“发散引用” - 不能靠改写 JOIN 顺序解决（如把
t3提前），必须打破拓扑：要么用 CTE 预聚合一边，要么把其中一个LEFT JOIN改成标量子查询（(SELECT ... FROM t2 WHERE ...)），要么确认业务允许时改用INNER JOIN - Oracle 12c+ 可尝试
OUTER APPLY，但要注意它仅支持单个右表，仍不能同时OUTER APPLY t2和OUTER APPLY t3
真正难调试的，永远不是报错的 SQL，而是那些静默退化成全表扫描、还自以为走对了索引的 OUTER JOIN。
