MySQL不支持标准MERGE语句，需用INSERT ... ON DUPLICATE KEY UPDATE替代；其核心是依赖主键或唯一键冲突触发更新，支持嵌套子查询（须独立且不引用目标表），并使用VALUES()安全取值。
MySQL不支持MERGE，得换思路
MySQL 8.0 仍不支持标准 MERGE 语句，直接写会报错 ERROR 1064 (42000)。如果你在 MySQL 里看到别人用了 MERGE，大概率是误传、用的 MariaDB（部分版本支持但语法受限），或者底层其实是 INSERT ... ON DUPLICATE KEY UPDATE 或 REPLACE INTO 伪装的。真要带嵌套子查询做 upsert 同步，得靠这俩替代方案，且嵌套子查询必须能被 MySQL 的 DML 子查询规则接受——比如不能引用目标表（INSERT 的目标表）本身。
用 INSERT ... ON DUPLICATE KEY UPDATE 嵌套子查询的写法
这是最接近 MERGE 行为的方案，前提是目标表有 PRIMARY KEY 或 UNIQUE 约束。嵌套子查询放在 VALUES 或 SELECT 子句里都行，但注意：子查询不能直接引用将要更新的同一张表（即不能在 ON DUPLICATE KEY UPDATE 的表达式里查目标表），否则报 ERROR 1093。
常见写法示例：
INSERT INTO orders (order_id, customer_name, total_amount)
SELECT src.order_id, src.customer_name, src.total_amount
FROM (
SELECT
o.id AS order_id,
c.name AS customer_name,
o.amount AS total_amount
FROM staging_orders o
JOIN staging_customers c ON o.customer_id = c.id
WHERE o.updated_at > '2024-01-01'
) AS src
ON DUPLICATE KEY UPDATE
customer_name = VALUES(customer_name),
total_amount = VALUES(total_amount);
关键点：
-
VALUES(col)是安全的取值方式，避免在UPDATE子句里重复写子查询 - 嵌套子查询（
src）必须是完整独立的SELECT，不能含对orders表的引用 - 如果子查询结果含重复
order_id，MySQL 按照唯一键冲突顺序逐条处理，行为可预期但不可并行优化
PostgreSQL 中 MERGE + 嵌套子查询的注意事项
PostgreSQL 15+ 支持标准 MERGE，但嵌套子查询只能出现在 USING 子句中，不能直接塞进 WHEN MATCHED THEN UPDATE SET ... 的表达式里——否则报 ERROR: cannot use subquery in this context。
正确写法是把逻辑提前收拢到 USING 的派生表中：
MERGE INTO orders t
USING (
SELECT
o.id,
o.customer_name,
o.total_amount,
c.region
FROM staging_orders o
LEFT JOIN customers c ON o.customer_id = c.id
WHERE o.status = 'confirmed'
) s
ON (t.order_id = s.id)
WHEN MATCHED THEN
UPDATE SET
customer_name = s.customer_name,
total_amount = s.total_amount,
region = s.region
WHEN NOT MATCHED THEN
INSERT (order_id, customer_name, total_amount, region)
VALUES (s.id, s.customer_name, s.total_amount, s.region);
容易踩的坑：
-
USING子查询里不能有聚合或窗口函数，除非外层包一层，否则MERGE解析失败 -
ON条件只支持等值匹配（=），不支持IS NOT DISTINCT FROM或函数表达式 - 如果
USING结果里同一id出现多次，PostgreSQL 会报ERROR: merge key column contains duplicate values，必须提前去重
嵌套子查询性能和锁行为的真实影响
不管用哪种方案，嵌套子查询一旦变复杂（比如多层 JOIN + WHERE 过滤 + 函数计算），就会显著拖慢整个 upsert 流程。更隐蔽的问题是锁：MySQL 的 INSERT ... ON DUPLICATE KEY UPDATE 在匹配阶段会对所有扫描到的唯一索引记录加 INSERT INTENTION + X 锁；PostgreSQL 的 MERGE 则会对 USING 结果集涉及的源行和目标行都加行级锁，且持续到事务结束。
实际同步大表时建议：
- 给
USING或子查询中的关联字段建好索引，特别是staging_orders.updated_at和连接键 - 避免在子查询里用
SELECT *，只取真正需要的列，减少网络和内存开销 - 如果源数据量超 10 万行，别一次性跑完，拆成按时间/ID 范围分批，用
WHERE id BETWEEN ? AND ?控制批次大小
嵌套子查询本身不难写，难的是它让执行计划变得不透明，出问题时很难一眼看出是子查询慢、锁等待长，还是唯一键冲突逻辑写错了。
