SQL MERGE 仅支持单表更新，所谓“多表更新”实为通过子查询预聚合多源数据后操作；错误写法如多表JOIN直接更新会报语法错，且ON条件不当易致全表误更新。
SQL MERGE 不能直接更新多张目标表
标准 SQL 的 MERGE 语句只支持单个 target table，所谓“多表更新”其实是常见误解。你看到的“MERGE 多表”，基本是把多张源表先 JOIN 成一张逻辑视图再喂给 MERGE，或者用多个独立 MERGE 语句分步操作。
典型错误现象：ERROR: syntax error at or near "FROM"（PostgreSQL）、Incorrect syntax near the keyword 'JOIN'（SQL Server）——这些都在提醒你：别在 MERGE 的 USING 子句里直接写多表 JOIN 后还试图更新另一张表。
- SQL Server 和 Oracle 支持
USING后跟子查询，可以SELECT ... FROM t1 JOIN t2 ON ...构建宽表，但最终INTO只能指定一张表 - PostgreSQL 不原生支持
MERGE（14+ 才有实验性支持），多数人用INSERT ... ON CONFLICT或WITH upsert AS (...) UPDATE ... FROM upsert替代 - MySQL 完全没有
MERGE，得靠INSERT ... ON DUPLICATE KEY UPDATE或分步UPDATE+INSERT
用子查询合并多源数据再 MERGE 是最稳妥做法
想基于订单、用户、商品三张表的数据去更新库存表，正确路径是：先把三张表按业务逻辑 JOIN 出一个带 sku_id、delta_qty、updated_at 的中间结果，再把这个结果作为 USING 的来源。
关键点在于：子查询必须明确可更新字段与匹配键，且不能含不确定行（比如一对多未聚合就 JOIN）。
- 避免在子查询里用
LEFT JOIN引入 NULL 导致ON匹配失败；宁可用INNER JOIN+ 补缺逻辑 - 聚合计算（如汇总订单数量）必须在子查询内完成，
MERGE本身不支持对源做聚合 - Oracle 中子查询若含
ROWNUM或分析函数，可能触发ORA-38104（无法更新 ON 条件中引用的列），要提前投影出确定列
示例（SQL Server）：
MERGE INTO inventory AS tgt USING ( SELECT o.sku_id, SUM(o.qty) AS delta, MAX(o.created_at) AS last_update FROM orders o INNER JOIN users u ON o.user_id = u.id AND u.status = 'active' GROUP BY o.sku_id ) AS src ON tgt.sku_id = src.sku_id WHEN MATCHED THEN UPDATE SET qty = qty + src.delta, updated_at = src.last_update WHEN NOT MATCHED THEN INSERT (sku_id, qty, updated_at) VALUES (src.sku_id, src.delta, src.last_update);
MERGE 的 ON 条件写错会导致全表误更新
ON 子句不是过滤条件，而是决定哪行“算匹配”。一旦写成恒真（如 ON 1=1）或漏掉关键约束，WHEN MATCHED 就会批量更新整张目标表——这比手抖删库还难回滚。
真实踩坑场景：开发为“保险起见”把 ON 写成 tgt.id = src.id OR tgt.code = src.code，结果因 code 允许 NULL 或存在重复，触发笛卡尔式匹配。
- 始终确保
ON中的字段在目标表上有唯一性保障（主键/唯一索引），否则加WHERE过滤也不起作用 - 测试阶段务必加
SELECT COUNT(*) FROM target WHERE [on-condition]验证匹配行数是否合理 - 生产环境执行前，先用
SELECT * FROM (subquery) src JOIN target tgt ON [same condition]看实际匹配效果
不同数据库对 MERGE 的兼容性差异极大
别指望一条 MERGE 语句在 PostgreSQL、SQL Server、Oracle 之间无缝迁移。语法糖、锁行为、事务可见性都不同。
比如 Oracle 的 MERGE 默认允许 UPDATE 和 INSERT 并存，而 SQL Server 要求 WHEN MATCHED 和 WHEN NOT MATCHED 必须成对出现（除非显式禁用某一分支）；PostgreSQL 15 的 MERGE 还不支持 DELETE 分支。
- SQL Server 中
MERGE有著名的 Halloween Problem 风险，大表更新建议加OPTION (LOOP JOIN)控制执行计划 - Oracle 的
MERGE在并行 DML 下可能跳过触发器，需确认ALTER SESSION ENABLE PARALLEL DML是否启用 - 跨库迁移时，优先考虑用标准
INSERT ... SELECT+UPDATE ... FROM拆解，虽然啰嗦但可控
复杂点从来不在语法本身，而在于你是否清楚自己写的 ON 条件在目标表数据分布下，到底会命中几行——这没法靠文档猜，只能查、要测、得留痕。
