Oracle 23ai中外连接性能退化主因是WHERE误用导致隐式转INNER JOIN、统计信息不准引发连接路径误选，以及BOOLEAN字段参与ON条件时索引失效；正确做法是将过滤条件移至ON子句、在连接列收集直方图、避免BOOLEAN字段直接用于外连接条件。
LEFT JOIN 和 RIGHT JOIN 在 Oracle 23ai 中仍沿用传统执行路径，但优化逻辑和陷阱比早期版本更隐蔽——尤其当搭配新特性（如 BOOLEAN 字段、VALUES 构造器或 RETURNING 子句）时，容易触发意料之外的执行计划退化。
外连接条件写在 ON 还是 WHERE？Oracle 23ai 里必须分清
很多人把过滤条件随手塞进 WHERE，结果把 LEFT JOIN 变成了隐式 INNER JOIN。比如：
SELECT e.name, d.dept_name FROM employees e LEFT JOIN departments d ON e.dept_id = d.id WHERE d.active = 1;
这个 WHERE 会过滤掉所有 d.active IS NULL 的左连接行（即员工没部门的记录），实际等效于内连接。正确写法是把业务过滤移到 ON：
SELECT e.name, d.dept_name FROM employees e LEFT JOIN departments d ON e.dept_id = d.id AND d.active = 1;
-
ON中的条件只影响右表匹配逻辑，不筛左表主行 - 若需保留左表全部记录 + 只取右表中 active=1 的匹配项，就必须用
AND跟在ON后 - Oracle 23ai 的优化器对
ON内复杂表达式（如函数、BOOLEAN字段判断）仍不够敏感，尽量避免在ON里写TO_CHAR(d.created_date) = '2024'这类操作
外连接 + 统计信息不准，执行计划会“装瞎”
Oracle 23ai 的 CBO（基于成本的优化器）依赖统计信息决定是否走嵌套循环（NL）还是哈希连接（HASH JOIN）。外连接特别容易因统计偏差选错路径：
- 如果
departments表被误判为“小表”，优化器可能强行用 NL 驱动，导致数十万行员工逐条 probe 部门表 -
DBMS_STATS.GATHER_TABLE_STATS必须在连接字段上收集直方图（method_opt => 'FOR COLUMNS dept_id SIZE AUTO'），否则对倾斜数据（比如 90% 员工都在 dept_id=1）完全无感知 - 23ai 新增的
SQL Domain类型字段若参与外连接，统计信息默认不采集，需显式调用DBMS_STATS.GATHER_COLUMN_STATS单独处理
用 MERGE 或 UNION ALL 替代复杂外连接？别盲目
有人看到外连接性能差就想着拆成 INNER JOIN + NOT EXISTS 再 UNION ALL，但在 23ai 里这未必更快：
-
UNION ALL方案需要两次全表扫描 + 一次去重（即使标了ALL，优化器有时仍加SORT UNIQUE） -
MERGE语句虽支持RETURNING，但仅限 DML 场景；纯查询不能用它替代LEFT JOIN - 真正有效的替代是：确认右表有高效访问路径（比如
dept_id上有索引且active字段选择性高），再配合/*+ USE_HASH(d) */提示强制哈希连接——23ai 对 hint 的兼容性比 19c 更稳
23ai 特有坑：BOOLEAN 字段参与外连接时索引失效
Oracle 23ai 允许建 BOOLEAN 列，但外连接中用它做 ON 条件时，哪怕该列上有函数索引，优化器也大概率忽略：
CREATE INDEX idx_dept_bool ON departments (CASE WHEN is_active THEN 1 ELSE 0 END);
上面这个索引，在 LEFT JOIN ... ON d.id = e.dept_id AND d.is_active = TRUE 中不会被使用。原因在于：
-
BOOLEAN是 SQL 层类型，底层存储仍是NUMBER(1)，但优化器尚未将布尔表达式与数值索引自动映射 - 临时解法：改用显式数值比较，比如
AND d.is_active_num = 1（把布尔字段存为NUMBER并建普通索引） - 长期建议：避开在连接条件中直接用
BOOLEAN字段，尤其在外连接场景下
ON 条件、统计精度、新数据类型三者耦合在一起。最容易被忽略的是：哪怕你用了最新版，BOOLEAN 字段和外连接仍是“危险组合”，上线前务必跑 EXPLAIN PLAN 看真实 access_predicates。 
