MERGE INTO不是“存在就更新”的快捷键，而是需手动清理源数据、固化匹配逻辑的原子操作；常见ORA-30926错误源于USING子查询返回重复键，须用ROW_NUMBER()去重并前置业务过滤条件，配合目标表索引与分批处理优化性能。
MERGE INTO 不是“存在就更新”的快捷键，而是需要你亲手把源数据理干净、把匹配逻辑钉死的原子操作。直接拿两张表硬连，90%概率触发 ORA-30926 或性能雪崩。
ORA-30926 报错的根本原因：USING 子查询返回了重复键
这个错误不是语法写错了，是 Oracle 在告诉你：“我没法确定该用哪一行去更新目标记录”。常见于源表含历史变更、全量导出残留、或没做去重聚合。
- 典型诱因：
SELECT id, name FROM source_table直接进USING，而source_table里有多个id = 1001的记录（比如某用户一天内被修改三次） - 错误表现：语句执行中断，报
ORA-30926: unable to get a stable set of rows in the source tables - 正确做法：必须在
USING子查询里加ROW_NUMBER()归并最新状态MERGE INTO target t USING ( SELECT id, name, update_time, ROW_NUMBER() OVER (PARTITION BY id ORDER BY update_time DESC) AS rn FROM source WHERE update_time > SYSDATE - 1 ) s ON (t.id = s.id AND s.rn = 1) WHEN MATCHED THEN UPDATE SET t.name = s.name WHEN NOT MATCHED THEN INSERT (id, name) VALUES (s.id, s.name);
为什么 ON 条件不能只写主键？还要加过滤逻辑
只写 ON (t.id = s.id) 看似合理，但实际会让无效行“卡”在匹配流程里——比如源数据中 status IS NULL 或 create_time < sysdate - 30 的脏数据，它们能匹配上，却不该参与更新或插入。
- 后果：无意义的 UPDATE 写放大、锁住不该锁的行、甚至覆盖掉有效数据
- 推荐写法：把业务有效性判断前置到
USING子查询的WHERE中，而不是塞进ON或WHEN MATCHED ... WHERE - 示例：
USING (SELECT * FROM source WHERE status IN ('ACTIVE', 'PENDING') AND create_time >= TRUNC(SYSDATE)) - 避免陷阱：
ON (t.id = s.id AND s.status = 'ACTIVE')是错的——它会让s.status != 'ACTIVE'的行既不走WHEN MATCHED也不走WHEN NOT MATCHED，直接丢弃
千万级表同步慢？问题不在 MERGE 语法，而在执行计划
默认情况下，Oracle 对 MERGE INTO 倾向使用嵌套循环 + 全表扫描，尤其当目标表 t 缺少索引、或 ON 字段选择性差时，性能会断崖下跌。
- 关键优化点：
ON字段必须在目标表上有高效索引（最好是唯一索引或主键） - 检查方式：执行
EXPLAIN PLAN FOR ...后查PLAN_TABLE，确认是否走了INDEX RANGE SCAN或UNIQUE SCAN，而非FULL TABLE SCAN - 分批处理建议：对超大源表，不要一次
USING source_table，改用时间范围或 ID 分段，例如WHERE id BETWEEN 1000000 AND 2000000 - 禁止行为：在
USING子查询里写(SELECT MAX(x) FROM t3)这类标量子查询，会导致优化器放弃哈希连接，强制走嵌套循环
UPDATE 和 INSERT 都要加 WHERE 条件？别乱动分支条件
WHEN MATCHED THEN UPDATE ... WHERE 和 WHEN NOT MATCHED THEN INSERT ... WHERE 是合法语法，但滥用会破坏增量语义。
- 典型误用：给
INSERT加WHERE s.amount > 0，结果导致本该新增的有效记录被跳过 - 合理场景仅限：防止无谓更新（如
WHEN MATCHED THEN UPDATE SET t.val = s.val WHERE t.val != s.val），避免日志膨胀和锁升级 - 注意：Oracle 不支持
WHEN NOT MATCHED BY SOURCE（那是 SQL Server 的语法），想处理“目标有、源没有”的记录，得另起一条DELETE语句或用物化视图日志 - 真正该加条件的地方，永远是
USING子查询的WHERE，不是分支里的WHERE
最常被忽略的一点：MERGE 的原子性只保证单条语句内的一致性，不保证跨语句的幂等。如果你的调度系统可能重跑任务，必须确保 USING 子查询每次取的都是同一窗口的数据（比如固定时间戳或批次号），否则第二次运行会把已同步的旧快照又插一遍。
