MERGE 不支持双向同步，因其语法和执行模型仅允许单向（源→目标）操作，缺乏反向扫描与差异暂存能力，强行双向会导致报错或数据混乱。
MERGE 不能实现双向同步，它只支持单向（源 → 目标）的条件化写入。试图用单条 MERGE 语句让两张表互相更新，会直接报错或产生不可控的数据覆盖——因为 MERGE 的 USING 子句指定唯一源，INTO 指定唯一目标，语法上就不允许“你同步我、我再同步你”这种循环逻辑。
为什么 MERGE 的设计天然排斥双向同步
MERGE 的执行模型是：逐行扫描 USING 表（源），对每行尝试匹配 INTO 表（目标）中满足 ON 条件的记录，然后根据匹配结果执行 INSERT/UPDATE/DELETE 中的**一个分支**。它没有“反向扫描”机制，也没有“暂存双方差异”的能力。
常见错误现象包括：
- 误以为加两个
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 语句关键得多。
