mysql不支持merge，需用insert...on duplicate key update替代；postgresql用insert...on conflict；sql server支持标准merge但需防死锁；跨库兼容只能靠应用层逻辑+行级锁。
MySQL 不支持 MERGE，得用 INSERT ... ON DUPLICATE KEY UPDATE 替代
MySQL 根本没有 MERGE 语句，直接写会报错 ERROR 1064 (42000)。这不是语法写错，是压根没实现。真实场景里，比如同步订单状态、更新用户积分，你得靠 INSERT ... ON DUPLICATE KEY UPDATE 模拟合并逻辑。
注意点：
-
ON DUPLICATE KEY UPDATE只触发于主键或唯一索引冲突，普通索引不生效 - 如果表没定义任何唯一约束，这条语句就退化成纯
INSERT，不会更新 - 更新字段不能引用刚插入的值（比如
SET cnt = cnt + 1是合法的，但SET name = VALUES(name)在旧版本 MySQL 中可能报错） - 性能上，它本质是“先试插，冲突再更新”，对高并发写入有锁竞争，比原生
MERGE多一次索引查找
PostgreSQL 用 INSERT ... ON CONFLICT，但语法细节和触发条件很关键
PostgreSQL 的等价写法是 INSERT ... ON CONFLICT，不是 MERGE。它支持更细粒度控制：能指定具体哪个约束（ON CONFLICT ON CONSTRAINT xxx）或哪组列（ON CONFLICT (user_id, dt)），这点比 SQL Server 更灵活。
常见翻车点：
- 漏写
DO UPDATE SET或DO NOTHING，语句直接报错syntax error at or near "on" - 在
DO UPDATE子句里引用EXCLUDED别名时拼错，比如写成exluded.name→ 报column "exluded" does not exist - 如果目标列有
DEFAULT值或GENERATED表达式，EXCLUDED里不会包含它们，需显式写出默认逻辑 - 性能上，它和 MySQL 类似，也是“插入试探+冲突处理”两阶段，但 PostgreSQL 9.5+ 对
ON CONFLICT做了锁优化，比 MySQL 的ON DUPLICATE KEY UPDATE并发表现略好
SQL Server 的 MERGE 是真 MERGE，但必须加 OPTION (LOOP JOIN) 防坑
SQL Server 是少数真正实现标准 MERGE 语句的数据库，语法最接近 ANSI SQL。但它有个隐藏雷区：当源数据量大、连接条件无索引时，优化器可能选错执行计划，导致全表扫描 + 死锁，错误信息常是 Msg 1205, Level 13, State 57（死锁牺牲品）。
实操建议：
- 务必在
USING子句的关联字段上建索引，尤其是ON条件里的列 - 加
OPTION (LOOP JOIN)强制使用嵌套循环，避免哈希/合并连接引发的内存暴涨或阻塞 -
MERGE语句里不能直接用子查询做USING源，得先WITH或临时表物化，否则报The MERGE statement attempted to UPDATE or DELETE the same row more than once - 性能优势明显：单次扫描完成匹配+插入+更新，比拆成
INSERT+UPDATE两步快 30%~50%，尤其在批量同步场景
跨库兼容写法只能取交集，别碰高级特性
想写一份 SQL 同时跑在 MySQL / PostgreSQL / SQL Server 上？放弃 MERGE 吧。三者语法差异太大，连关键字都不同：ON DUPLICATE KEY UPDATE、ON CONFLICT、MERGE 互不兼容。唯一可行的“兼容层”是用应用层逻辑：先 SELECT 查是否存在，再分路 INSERT 或 UPDATE。
但要注意：
- 这会把原本一次网络往返变成两次，延迟翻倍，且中间可能被其他事务修改（丢失更新）
- 必须加
SELECT ... FOR UPDATE（PostgreSQL/MySQL）或WITH (UPDLOCK)（SQL Server）来防并发，否则逻辑就不可靠 - 哪怕只用基础语法，
INSERT IGNORE（MySQL）、INSERT ... ON CONFLICT DO NOTHING（PG）、MERGE（SQL Server）三者对“忽略重复”的语义也不一致：有的跳过整行，有的只跳过冲突字段 - 真正复杂的合并逻辑（比如根据条件决定更新还是删除），跨库时几乎必然要分库写，别硬凑
多数据库环境里，“兼容”往往意味着放弃一部分能力，而不是找到一个万能写法。写之前先确认：到底是真需要跨库执行，还是只是开发环境想少改几行？后者其实用方言适配器更省事。
