oracle子查询更新易出错，需用where exists避免null，rownum=1防ora-01427；一对多场景应改用merge into并显式去重。
UPDATE 语句里用子查询更新，Oracle 是支持的，但极易出错、性能差、且行为反直觉——不是语法写对就能跑通，关键得让 Oracle 认为“这行能安全改”。
为什么 UPDATE ... SET col = (SELECT ...) 常报 ORA-01427 或设成 NULL
子查询返回多行 → 直接抛 ORA-01427: single-row subquery returns more than one row；没加 WHERE EXISTS → 匹配不上的行会被设成 NULL（不是跳过，是真清空）。这两个问题几乎必现，尤其当关联字段没建唯一索引时。
常见错误写法：
UPDATE t1 SET name = (SELECT name FROM t2 WHERE t2.id = t1.id);
它会：① 对 t1 每一行都执行一次子查询；② 若某行在 t2 中无匹配，子查询返回空，name 被赋值为 NULL；③ 若某行在 t2 中有两条匹配，直接报错。
- 必须加
WHERE EXISTS(...)控制更新范围，避免误置NULL - 子查询里
WHERE的关联条件，必须能走索引（最好是t2.id为主键或唯一索引） - 别指望优化器自动去重——它不会帮你加
DISTINCT或ROWNUM = 1，你得自己兜底
怎么写才不容易报错：带 EXISTS + 显式单值保障
核心是两层过滤：外层 WHERE EXISTS 确保只更新有匹配的行；内层子查询确保最多返回一行。哪怕源表有脏数据，也要主动截断。
推荐写法：
UPDATE t1
SET status = (
SELECT /*+ FIRST_ROWS(1) */ new_status
FROM t2
WHERE t2.order_id = t1.order_id
AND ROWNUM = 1
)
WHERE EXISTS (
SELECT 1 FROM t2 WHERE t2.order_id = t1.order_id
);
-
ROWNUM = 1是硬性兜底，防止ORA-01427；但注意它不保证逻辑一致性（比如选哪条算“最新”得靠ORDER BY配合物化视图或子查询排序，原生ROWNUM不支持） -
/*+ FIRST_ROWS(1) */提示优化器尽早终止扫描，对大表有实际收益 -
EXISTS子查询和主查询的关联字段，必须和内层子查询一致，否则可能漏更新或计划失真
什么时候该放弃子查询 UPDATE，直接切到 MERGE INTO
只要满足以下任一条件，就该换 MERGE INTO：
- 要更新的行数 > 1000
- 关联表
t2和目标表t1是一对多关系（比如一个订单对应多条明细） - 你发现执行计划里出现多次
t2全表扫描或嵌套循环（NESTED LOOPS） - 需要后续扩展成“有则更新、无则插入”
MERGE INTO 不依赖子查询单行语义，而是靠 ON 条件一次性定位匹配行。只要 ON 里用了 t1 的主键，就不会触发 ORA-01779。
示例（安全替代上面的更新）：
MERGE INTO t1 USING (SELECT DISTINCT order_id, new_status FROM t2) src ON (t1.order_id = src.order_id) WHEN MATCHED THEN UPDATE SET t1.status = src.new_status;
注意：USING 子查询必须显式去重（DISTINCT 或聚合），否则一对多仍会导致重复匹配——MERGE 不报错，但会按最后一条覆盖，结果不可控。
容易被忽略的执行细节：索引不是写了就有用
即使你在 t2.id 上建了主键，如果 UPDATE 语句里写的是 t2.code = t1.code，而 code 列没索引，Oracle 依然会全表扫描 t2 每次——因为子查询是逐行执行的。
验证方法：看执行计划里子查询部分是否出现 INDEX RANGE SCAN 或 INDEX UNIQUE SCAN。如果没有，加索引只是第一步，你还得确认 SQL 实际用了它。
另一个坑：EXISTS 子查询和 SET 子查询，优化器可能生成不同访问路径。别假设它们共享执行计划——最好用 EXPLAIN PLAN FOR 分别看。
