MERGE INTO是Oracle唯一支持“存在则更新、不存在则插入”的原子操作，但直接用结构相同的表同步易因匹配逻辑失控、数据重复或事务边界不清而失败；需通过ROW_NUMBER()去重、索引优化、分批处理及闪回验证确保稳定高效。
MERGE INTO 是 Oracle 中唯一能在一个原子语句里完成「存在则更新、不存在则插入」的机制，但直接拿两张结构相同的表 USING 另一张表做同步，大概率会出错或性能崩掉——关键不在语法对不对，而在你有没有控制好匹配逻辑、数据去重和事务边界。
为什么 MERGE INTO t1 USING t2 ON (t1.id = t2.id) 会失败或重复更新？
表面上看，两张结构相同的表用主键关联似乎天衣无缝。但真实场景中，t2 往往是增量快照、临时表或外部导入表，它本身可能含重复 id、脏数据、或未过滤的历史变更。Oracle 的 MERGE 要求 USING 子查询结果中，每个匹配键（如 id）最多只能有一行参与 WHEN MATCHED；否则报错 ORA-30926: unable to get a stable set of rows in the source tables。
常见诱因包括：
-
t2表里有多个相同id的记录（比如某订单被多次修改后全量导出） -
ON条件写成t1.id = t2.id AND t1.status = t2.status，导致部分t2行无法匹配，又没走INSERT分支（因为ON不成立 ≠NOT MATCHED） - 没加
WHERE过滤t2中无效数据（如status IS NULL或create_time ）
如何确保 USING 子句返回稳定、无歧义的源数据？
不能把原始表直接塞进 USING，必须先做一层清洗和归并。核心是：让每个目标键（如 id）在 USING 结果中至多出现一次，且代表该键的「最新有效状态」。
推荐做法：
- 用
ROW_NUMBER() OVER (PARTITION BY id ORDER BY update_time DESC, version DESC)去重，再外层WHERE rn = 1 - 若
t2是日志表或带操作类型（INSERT/UPDATE/DELETE），先FILTER WHERE op_type != 'DELETE'，再聚合 - 如果业务允许「跳过更新」（即已有数据不覆盖），就改用
WHEN NOT MATCHED THEN INSERT，并去掉WHEN MATCHED分支——这本质是增量追加，不是同步 - 避免在
USING子查询里调用函数或子查询（如(SELECT MAX(x) FROM t3)），会导致执行计划不可控、性能陡降
千万级表同步时，MERGE INTO 为什么越来越慢？
MERGE INTO 在大数据量下不是“语法问题”，而是“执行计划问题”。它默认走的是嵌套循环（NESTED LOOPS）+ 全表扫描，尤其当 t1 没有合适索引、或 ON 字段选择性差时，性能会断崖式下跌。
可验证和优化的点：
- 确认
t1上用于ON的字段（如id）有高效索引：CREATE INDEX idx_t1_id ON t1(id) ONLINE; - 强制走哈希连接（适合大表）：
/*+ USE_HASH(s,t) */加在USING子句前（注意 Oracle 版本兼容性） - 拆分批量：不要一次
MERGE百万行，按id范围或时间分区切片，配合COMMIT控制回滚段大小 - 关掉日志（仅限非生产调试）：
ALTER TABLE t1 NOLOGGING;，但上线前务必恢复
如何安全地验证 MERGE 结果而不锁表？
别在生产高峰期跑完就查 COUNT(*)——那会引发大量逻辑读和 latch 竞争。真正有效的验证是轻量、定向、可回退的。
建议组合动作：
- 执行前记下
t1的MIN(id), MAX(id), COUNT(*)和几个关键样本值（如SELECT id, name FROM t1 WHERE id IN (1001, 2005, 3009)） -
MERGE后立刻查SQL%ROWCOUNT（PL/SQL）或客户端返回的受影响行数，确认是否符合预期（比如你传了 5000 行源数据，INSERT了 3200，UPDATE了 1800） - 抽样比对：只查
WHERE id IN (SELECT id FROM t2 WHERE ROWNUM ，而非全表扫 - 用
DBMS_FLASHBACK或闪回查询（AS OF TIMESTAMP）快速回溯变更前状态，比备份恢复快得多
最常被忽略的一点：MERGE 的原子性只保证单条语句内一致，不保证跨语句或跨事务的业务一致性。比如你在 USING 里用了子查询依赖另一张控制表，而那个控制表又被其他进程并发修改——结果就是同步逻辑错乱。这种依赖必须显式加锁或走串行化事务隔离。
