MySQL不支持MERGE，需用INSERT ... ON DUPLICATE KEY UPDATE实现UPSERT；PostgreSQL用INSERT ... ON CONFLICT；SQL Server和Oracle支持MERGE但语法严格且易错。
MySQL不支持MERGE，得用REPLACE INTO或INSERT ... ON DUPLICATE KEY UPDATE
MySQL从8.0开始仍不支持标准SQL的MERGE语句，直接写会报错ERROR 1064 (42000)。想实现UPSERT（存在则更新、不存在则插入），必须换语法。
推荐用INSERT ... ON DUPLICATE KEY UPDATE：它只触发一次写入，能复用唯一索引（PRIMARY KEY或UNIQUE约束）做判断，且支持部分字段更新，语义清晰。
- 必须确保目标表有明确的唯一约束，否则
ON DUPLICATE KEY UPDATE不会生效 -
REPLACE INTO本质是DELETE + INSERT，在有外键或触发器时行为不可控，还可能引发自增ID跳变 - 如果更新字段依赖原值（比如计数器+1），写成
cnt = cnt + 1即可，无需子查询
INSERT INTO users (id, name, score) VALUES (123, 'Alice', 85) ON DUPLICATE KEY UPDATE name = VALUES(name), score = VALUES(score);
PostgreSQL用INSERT ... ON CONFLICT实现等效MERGE
PostgreSQL没有MERGE，但INSERT ... ON CONFLICT功能更细粒度——可指定冲突目标（不止是主键）、支持DO NOTHING或DO UPDATE，并能引用EXCLUDED伪表。
关键点在于ON CONFLICT后要明确冲突列，不能只写ON CONFLICT ON CONSTRAINT pk_users（除非你真定义了命名约束）。
- 常见错误：漏写
WHERE条件导致不该更新的行也被覆盖，比如只希望更新非空值：SET name = EXCLUDED.name WHERE EXCLUDED.name IS NOT NULL -
EXCLUDED是固定关键字，代表本次试图插入的那行数据，不能写成NEW或别名 - 如果冲突列是组合唯一索引，需写全字段：
ON CONFLICT (user_id, category)
INSERT INTO users (id, name, updated_at) VALUES (123, 'Alice', NOW()) ON CONFLICT (id) DO UPDATE SET name = EXCLUDED.name, updated_at = NOW();
SQL Server真正支持MERGE，但语法严格、易出错
SQL Server的MERGE是标准实现，但要求源数据必须来自SELECT（不能直接VALUES），且WHEN MATCHED和WHEN NOT MATCHED分支必须显式写出，少一个就报错。
最常踩的坑是JOIN条件写错导致误更新/误插入，或者没加AND过滤条件让WHEN MATCHED更新了本不该动的行。
- 必须用
AS source给输入数据起别名，否则ON子句里无法引用字段 -
WHEN MATCHED THEN UPDATE SET ...默认更新所有匹配行，务必加AND限定条件，例如AND source.updated_at > target.updated_at - 执行前建议先用
SELECT模拟源数据，确认ON条件返回的匹配关系符合预期
MERGE users AS target USING (SELECT 123 AS id, 'Alice' AS name, GETDATE() AS updated_at) AS source ON target.id = source.id WHEN MATCHED THEN UPDATE SET name = source.name, updated_at = source.updated_at WHEN NOT MATCHED THEN INSERT (id, name, updated_at) VALUES (source.id, source.name, source.updated_at);
Oracle MERGE的UPDATE/INSERT子句不能共用同一别名
Oracle的MERGE语法最接近SQL标准，但有个隐蔽限制：在UPDATE SET和INSERT VALUES中，不能直接用源表字段名，必须统一通过source_alias.column引用，且这个别名在两个子句里必须一致。
容易忽略的是UPDATE子句里不能出现目标表字段的计算逻辑（比如score = score + 1），必须改用source提供完整值或用子查询。
- 别名不能省略，写
USING (SELECT ...) s后，后续所有s.name都必须带s.前缀 -
UPDATE子句中若要保留原字段值，需在USING子查询里显式SELECT出来，不能靠target.column回读 - 如果源数据来自大表，
USING子查询最好提前加索引或限制结果集，否则MERGE性能会断崖下跌
MERGE INTO users t USING (SELECT 123 id, 'Alice' name, SYSDATE updated_at FROM DUAL) s ON (t.id = s.id) WHEN MATCHED THEN UPDATE SET t.name = s.name, t.updated_at = s.updated_at WHEN NOT MATCHED THEN INSERT (id, name, updated_at) VALUES (s.id, s.name, s.updated_at);
跨数据库写UPSERT时，最麻烦的不是语法差异，而是对“冲突判定依据”的理解是否一致——有人以为主键相同就算冲突，实际业务可能要求按业务码+租户ID联合判断。这种逻辑一旦写死在SQL里，后续改起来比迁库还痛。
