merge 不支持双向同步，因其语法和执行模型仅允许单向（源→目标）操作，缺乏反向扫描与差异暂存能力，强行双向会导致报错或数据混乱。

MERGE 不能实现双向同步，它只支持单向（源 → 目标）的条件化写入。试图用单条 MERGE 语句让两张表互相更新，会直接报错或产生不可控的数据覆盖——因为 MERGE 的 USING 子句指定唯一源，INTO 指定唯一目标，语法上就不允许“你同步我、我再同步你”这种循环逻辑。

为什么 MERGE 的设计天然排斥双向同步

MERGE 的执行模型是：逐行扫描 USING 表（源），对每行尝试匹配 INTO 表（目标）中满足 ON 条件的记录，然后根据匹配结果执行 INSERT/UPDATE/DELETE 中的**一个分支**。它没有“反向扫描”机制，也没有“暂存双方差异”的能力。

常见错误现象包括：

Musho

Musho是一款用于从提示词快速生成网站和应用界面设计的 AI UI 工具。

下载

• 误以为加两个 MERGE（A→B 和 B→A）就是双向，结果因执行顺序、并发修改或未处理冲突导致数据来回翻转
• 在 ON 条件中混用双向字段（如 ON a.id = b.id OR a.ts > b.ts），触发多匹配，违反 MERGE 要求的“至多一个匹配行”约束，报错 ORA-30926: unable to get a stable set of rows in the source tables（Oracle）或类似提示
• 忽略时钟不同步或无全局单调时间戳，导致基于时间的“谁更新得晚谁生效”逻辑失效

真正可行的双向同步替代方案

必须跳出单语句思维，把问题拆解为“检测差异 + 安全应用”。常用路径有：

• 用变更日志（CDC）驱动：监听源表的 INSERT/UPDATE/DELETE 日志（如 MySQL binlog、PostgreSQL logical replication、SQL Server CDC），将操作重放至目标表；反过来再部署一套监听目标表日志并回写源表。需额外组件（如 Debezium、Flink CDC）和幂等设计
• 基于时间戳/版本号的双写比对：要求两张表都有 last_modified 字段且能保证时钟基本一致。先查 A 表中比 B 表新（a.ts > max(b.ts)）的记录同步到 B；再查 B 表中比 A 表新的记录同步到 A。必须加分布式锁或串行化事务，否则竞态下会丢更新
• 用临时表+分步 MERGE 模拟：不推荐，但若强依赖 SQL 原生能力，可先用 SELECT ... EXCEPT 或 NOT EXISTS 找出 A 有而 B 无的行，INSERT 进 B；再找 B 有而 A 无的行，INSERT 进 A；最后对共有的行，按业务规则（如取较新时间戳）生成中间结果集，用 MERGE 更新 B —— 注意这仍是两阶段，且无法原子化

如果坚持用 MERGE，必须守住的底线

哪怕只做单向同步，MERGE 的实际效果也高度依赖细节：

• ON 条件必须能唯一确定目标行，避免多匹配。例如用主键或唯一索引列，别用模糊字段（如 name）
• WHEN MATCHED THEN UPDATE 中，显式列出要更新的列，别用 SET (a,b,c) = (SELECT ...) 这种易出错的批量赋值
• Oracle/SQL Server 支持 WHEN NOT MATCHED BY SOURCE THEN DELETE，但 PostgreSQL 不原生支持；若需清理目标表中源已删除的记录，得额外写 DELETE 语句
• 大表同步前务必在 ON 字段上建索引，否则 MERGE 会退化成嵌套循环，性能断崖式下跌

双向同步的本质是分布式状态一致性问题，SQL 的 MERGE 只是一个单机、单向、非事务跨库的工具。真正落地时，冲突检测策略（比如遇到同 ID 同时间更新怎么选）、网络分区处理、回滚恢复路径，这些都远比写对一条 MERGE 语句关键得多。