MERGE INTO 是 SQL 中用于“存在则更新、不存在则插入”的原子操作，但不同数据库对多源更新（即从多个表或子查询合并数据）和冲突处理（如重复键、约束冲突）的支持差异显著。以下对比主流数据库的兼容性表现。
多源更新支持情况
标准 SQL-2003 仅定义单源 MERGE（USING 后接一个表或子查询），但实际中“多源”常指在 ON 条件或 WHEN MATCHED THEN UPDATE SET 中引用多个表别名，或通过 CTE/派生表间接组合数据。
-
PostgreSQL：不原生支持
MERGE（截至 v16），需用INSERT ... ON CONFLICT模拟；无法直接在ON CONFLICT中引用多表，但可通过 CTE 预聚合多源数据再执行 upsert。 -
SQL Server：支持
MERGE，USING可接 JOIN 后的派生表（如SELECT ... FROM A JOIN B ON ...），实现逻辑上的多源输入；UPDATE SET中可引用USING子句中所有别名字段。 -
Oracle：支持
MERGE，USING支持复杂子查询（含多表 JOIN、UNION、分析函数），且UPDATE和INSERT子句均可访问USING中所有列别名，多源灵活性高。 -
MySQL：无
MERGE语法，用INSERT ... ON DUPLICATE KEY UPDATE替代；仅支持单表INSERT，多源需先用临时表或 CTE（8.0+）预处理，再执行 upsert。
冲突检测与处理机制差异
冲突不仅指主键/唯一键重复，还包括外键约束、CHECK 约束触发、NULL 违反等。各数据库对冲突的捕获粒度和响应方式不同。
- SQL Server 的
MERGE在执行时对每个匹配行单独评估WHEN MATCHED/WHEN NOT MATCHED，若某行更新违反约束，整个语句回滚（默认事务行为）；不支持跳过单行错误继续执行。 - Oracle 允许在
MERGE中使用LOG ERRORS INTO子句，将违反约束的行写入错误日志表，其余行正常提交，实现“容错式合并”。 - PostgreSQL 的
ON CONFLICT必须显式指定冲突目标（如ON CONFLICT (id)或ON CONFLICT ON CONSTRAINT uk_name），不支持自动推断；若未覆盖所有可能冲突路径（如多唯一索引），可能抛出未捕获异常。 - MySQL 的
ON DUPLICATE KEY UPDATE仅响应PRIMARY KEY或UNIQUE INDEX冲突，对外键或 CHECK 约束失败直接报错，无重试或记录选项。
并发安全与锁行为关键区别
多用户环境下，MERGE 类操作易引发死锁或幻读，各数据库加锁策略影响实际可用性。
- SQL Server 对
MERGE目标表使用范围锁（Range Lock）或键锁（Key Lock），在ON条件涉及非索引列时可能升级为表锁，阻塞并发读写。 - Oracle 默认使用行级锁 + SELECT FOR UPDATE 语义隐式保障一致性，MERGE 过程中对匹配行加 X 锁，未匹配行不锁；若
ON条件无有效索引，可能全表扫描并锁大量无关行。 - PostgreSQL 基于 MVCC，
ON CONFLICT使用INSERT的意向锁 + 行级排他锁，但若冲突频繁，可能因多次重试导致性能下降；不锁未命中行。 - MySQL InnoDB 在
ON DUPLICATE KEY UPDATE中对冲突键加 record lock，对插入意向 gap lock，高并发下易出现死锁，尤其当多语句交叉更新同一键范围时。
实用建议：跨平台写法收敛策略
若需在多种数据库间复用 MERGE 逻辑，避免语法强耦合：
- 始终为
ON条件中的连接字段建立唯一索引或主键，减少锁范围和全表扫描风险。 - 多源数据优先在应用层或 CTE 中完成关联、去重、聚合，再传入单源 MERGE/UPSERT，降低数据库方言依赖。
- 对必须容忍部分失败的场景，Oracle 用
LOG ERRORS，PostgreSQL 用DO块 + 异常捕获，SQL Server 可拆分为先查后插/更两步并加重试逻辑。 - 测试阶段需覆盖“空源数据”“全匹配”“全不匹配”“部分冲突”四类边界，验证各库是否按预期执行分支逻辑而非静默忽略。
