Oracle外连接性能关键在执行计划是否走Hash Join及驱动表选择是否合理；(+)语法仅支持左/右外连接且易出错，LEFT JOIN更直观安全，全外连接必须用FULL OUTER JOIN。
Oracle外连接的高效处理，关键不在语法选型，而在执行计划是否走Hash Join + 驱动表选择是否合理；(+) 语法和 LEFT JOIN 在语义上等价，但混合使用会报错，且 (+) 无法表达全外连接。
什么时候该用 (+)，什么时候必须用 LEFT JOIN
(+) 是 Oracle 早期专有外连接写法，仅支持左/右外连接，且强制要求所有关联条件都带 (+)、只能出现在 WHERE 子句中。比如：
SELECT a.id, a.name, b.name FROM t_A a, t_B b WHERE a.id = b.id(+);
这个写法等价于 LEFT JOIN，但一旦混入其他条件（如 AND b.status = 'A'），就必须写成 b.status(+) = 'A'，否则逻辑错误——(+) 会把 b 整体当可空侧，不加 (+) 的条件会变成内连接过滤条件。
-
LEFT JOIN更直观，支持ON子句分离连接条件与过滤条件 -
(+)在复杂多表连接中极易漏写或错位，尤其涉及OR、IN、函数表达式时直接报错 - Oracle 12c+ 已明确建议弃用
(+)，全外连接FULL OUTER JOIN只能用标准语法
为什么 LEFT JOIN 查询变慢？先看执行计划里的驱动表
外连接性能瓶颈往往不是语法本身，而是优化器选错了驱动表。例如：
SELECT /*+ USE_HASH(a b) */ * FROM large_table a LEFT JOIN small_table b ON a.id = b.id;
如果 small_table 没有索引，而 large_table 有主键，Oracle 可能仍选 large_table 为驱动表，导致大量 NULL 补充操作拖慢速度。
- 外连接中，非空侧（即“被保留”的表）默认更可能成为驱动表，但不绝对
- 用
EXPLAIN PLAN FOR查看PLAN_TABLE中的id和parent_id，确认哪张表是 Hash Build 表（应是小表） - 必要时加
/*+ LEADING(a) USE_HASH(a b) */强制指定顺序，但需配合统计信息准确
WHERE 条件放 ON 还是放 WHERE，结果可能完全不同
这是外连接最易踩的坑：把本该在 ON 子句里的条件挪到 WHERE，会把外连接“退化”成内连接。
-- ✅ 正确：只对右表做关联过滤，左表记录全保留 SELECT a.id, b.status FROM t_A a LEFT JOIN t_B b ON a.id = b.id AND b.status = 'ACTIVE'; <p>-- ❌ 错误：WHERE 后的 b.status = 'ACTIVE' 会过滤掉所有 b 为 NULL 的行 SELECT a.id, b.status FROM t_A a LEFT JOIN t_B b ON a.id = b.id WHERE b.status = 'ACTIVE';
- 所有针对右表（空侧）的过滤条件，必须写在
ON子句里 -
WHERE子句只用于限制最终结果集，对左表字段过滤安全，对右表字段过滤则破坏外连接语义 - 用
(+)写法时，对应条件必须带(+)，否则同样失效
全外连接没索引时，为什么特别卡？
FULL OUTER JOIN 无法用单边 Hash Join 完成，Oracle 必须分别构建左右两表的 Hash 表，并做两次探测（左→右 + 右→左），内存和 CPU 开销翻倍。若任一表无有效索引，还可能触发大量磁盘排序。
- 避免在大表上直接用
FULL OUTER JOIN，优先考虑是否可用UNION ALL模拟（LEFT JOIN+RIGHT ANTI JOIN） - 确保连接字段有索引，且统计信息最新（
DBMS_STATS.GATHER_TABLE_STATS） - 如果只是想补 NULL，检查是否真需要全外——多数业务场景其实只需要左或右外
真正影响外连接效率的，从来不是括号加在哪，而是你有没有看过执行计划里那张被 hash 的表有多大、有没有被过滤条件悄悄“吃掉”了外连接特性。
