merge into 是 oracle 批量更新最稳妥的选择，因其原子性支持“存在则更新、不存在则插入”，避免 update+insert 组合的不可控风险与重复逻辑。
merge into 是 oracle 中批量更新最稳妥的选择，尤其当你要同时处理“已有记录就更新、没有就插入”这类逻辑时，它比写一堆 update + insert + exists 更可靠、更原子、也更容易控制条件。
为什么不能直接用 UPDATE 带子查询批量更新
Oracle 的 UPDATE 语句不支持在 SET 子句里直接关联多表（比如 UPDATE t1 SET col = (SELECT x FROM t2 WHERE t2.id = t1.id)），虽然语法上允许，但一旦子查询返回多行或 NULL，就会报 ORA-01427: single-row subquery returns more than one row 或静默设为 NULL，结果不可控。
常见踩坑点：
- 没加
DISTINCT或聚合，子查询对同一个id返回多条记录 - 源数据有重复键，但目标表主键/唯一约束没提前校验
- 子查询中用了
JOIN却没意识到会放大行数，导致更新错行
MERGE INTO 的 ON 条件必须满足唯一性
ON 子句定义的是“哪一行该被更新”，不是“哪几行可以参与匹配”。Oracle 要求：对目标表的每一行，最多只能有一行源数据满足 ON 条件。否则会报 ORA-30926: unable to get a stable set of rows in the source tables。
实操建议：
- 确保
USING后的子查询结果中，用于ON匹配的字段（如id）是唯一的 —— 加DISTINCT、GROUP BY或ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...)过滤 - 避免在
USING子句里直接JOIN多张业务表，容易引入隐式笛卡尔积；优先把逻辑收拢到子查询内部再聚合 - 测试时先跑
SELECT版本：SELECT * FROM (your USING subquery) s JOIN target t ON s.id = t.id，看是否出现一对多
UPDATE 和 INSERT 的字段必须显式对齐
WHEN MATCHED THEN UPDATE SET 后面不能写目标表不存在的列，也不能漏掉非空约束字段（除非你确认值不会为 NULL）；WHEN NOT MATCHED THEN INSERT 必须列出所有 NOT NULL 列，且 VALUES 顺序和列名顺序严格一致。
典型错误：
-
INSERT (a, b) VALUES (s.x, s.y, s.z)—— 值数量 > 列数量，报ORA-00947: not enough values - 目标表
last_updated是NOT NULL，但INSERT没给默认值（如SYSDATE），报ORA-01400: cannot insert NULL - 在
UPDATE里误写了SET t.id = s.id——ON条件列不允许更新，报ORA-00904: invalid identifier
性能关键：小表做源、大表做目标，别反着来
MERGE 的执行计划通常是 HASH JOIN，Oracle 默认把 USING 的源表当驱动表（build table）。如果源表很大（比如 800 万行），而目标表很小（20 万行），就会产生巨大哈希表，内存压力大、临时表空间暴涨，甚至 OOM。
优化方向：
- 源表务必走索引或提前过滤（
WHERE放在USING子查询内，别放外面） - 源表若含大量重复键，先用
GROUP BY或ROW_NUMBER()压缩，减少 JOIN 开销 - 目标表的
ON字段要有索引（尤其是主键或唯一键），否则全表扫描代价极高 - 大批次操作前，考虑加
/*+ APPEND */提示（仅限 INSERT 分支生效）或分批提交（用WHERE ROWNUM 控制子查询规模）
真正难搞的从来不是语法，而是你手里的源数据到底干不干净、目标表索引建没建对、以及那个看似简单的 ON 条件背后有没有隐藏的一对多关系 —— 这些地方一出错，MERGE 不会温柔提醒，只会直接报错或静默写错数据。
