必须用标准JOIN替代(+)：Oracle自11g起已弃用(+)，因其在多表连接中易致静默错误；LEFT/RIGHT JOIN严格分离ON与WHERE逻辑，避免外连接语义被破坏，且FULL OUTER JOIN无(+)等价写法。
直接结论：必须用 LEFT JOIN、RIGHT JOIN、FULL OUTER JOIN 替代 (+)，不是“可以”，而是“必须”——Oracle 官方自 11g 起就明确标记 (+) 为过时（deprecated），且它在复杂查询中极易引发静默错误。
为什么 (+) 在多表连接中会悄悄失效
当你写 WHERE a.id = b.id(+) AND b.status = 'A'，Oracle 实际只返回 b.status = 'A' 且能匹配的行，b 表中 status ≠ 'A' 的空值行被过滤掉了——这根本不是外连接本意，但不会报错，也不会警告。
原因在于：(+) 只控制“是否补 NULL”，不控制“过滤时机”。而标准 JOIN 把连接条件（ON）和过滤条件（WHERE）严格分离：
-
ON子句中的条件在连接时生效，不影响驱动表的完整性 -
WHERE子句中的条件在连接后生效，会筛掉整行（包括驱动表数据）
所以正确写法是：LEFT JOIN b ON a.id = b.id AND b.status = 'A' —— 这样才能保留所有 a 行，同时只匹配 b 中 status = 'A' 的记录（或 NULL）。
LEFT JOIN 和 RIGHT JOIN 怎么对应 (+) 的左右位置
记住一个口诀：加号在哪边，哪边就是“被补 NULL”的表；标准语法里，“JOIN”左边是驱动表，“JOIN”右边是被补表。
对照示例：
-
a.id = b.id(+)→a LEFT JOIN b ON a.id = b.id（a全部保留） -
a.id(+) = b.id→a RIGHT JOIN b ON a.id = b.id（b全部保留） - 多个条件必须全部带
(+)，否则退化为内连接；而ON后可自由组合，无此限制
特别注意：如果原 SQL 有 AND c.name IS NOT NULL 这类对右表字段的非空判断，不能直接挪到 WHERE，否则破坏外连接语义——应改写为 ON ... AND c.name IS NOT NULL 或使用 COALESCE(c.name, 'N/A') 等逻辑兜底。
重构时最容易踩的三个坑
迁移 200 个包不是体力活，而是逻辑校验活。以下三点不检查，上线必出数据差异：
-
(+)出现在子查询里？标准JOIN不支持子查询直接JOIN，得先用WITH或内联视图封装 - 原 SQL 用了
OR连接含(+)的条件？比如WHERE b.id(+) = a.id OR b.type = 'X'—— 这种写法本身非法，Oracle 会静默忽略外连接，必须拆成UNION ALL或重写逻辑 - 存在自连接 +
(+)？例如emp.mgr_id(+) = emp.emp_id是无效语法，但LEFT JOIN emp e2 ON emp.mgr_id = e2.emp_id完全合法且清晰
另外，FULL OUTER JOIN 在 (+) 里没有直接等价写法，只能靠 UNION ALL + NOT EXISTS 模拟，而标准语法一行搞定。
工具能自动转换，但不能替代人工验证
像 SQL Developer 的“Convert to ANSI Join”功能、或开源工具 ora2pg 都能批量替换基础 (+)，但它们无法识别上下文逻辑陷阱。例如：
原 SQL 中 WHERE d.dept_id(+) = e.dept_id AND d.active = 'Y'，工具可能机械转成 LEFT JOIN d ON d.dept_id = e.dept_id WHERE d.active = 'Y' —— 这实际变成了内连接，漏掉所有 e 对应 d 为空或 inactive 的员工。
真正安全的做法是：每条语句重构后，用小数据集跑 EXCEPT 对比（或 MINUS），确认结果行数与关键字段 NULL 分布完全一致。尤其关注那些原本就容易 NULL 的字段，比如部门名、上级姓名、配置项值。
