如何使用SQL MERGE语句简化复杂的更新需求
为什么 MERGE 比 UPDATE + INSERT 组合更可靠
说到底，MERGE 的核心优势在于“原子性”。它把匹配、插入、更新、删除这几件事，打包成一条不可分割的语句来执行。这恰恰解决了手动组合 UPDATE 和 INSERT 时最头疼的竞态问题：你想想，如果先查再更新，两次查询之间源数据要是变了，结果不是重复插入，就是漏了更新。而 MERGE 由数据库引擎保证整个匹配逻辑的原子性，尤其是在高并发数据同步的场景下，这几乎是最直接、最可靠的稳定性保障。
不过，想用好它，有几个实操细节必须盯紧：
- 索引是性能的生命线：务必为
MERGE语句中ON条件涉及的列建立索引。否则，一旦源表数据量大，或者目标表缺少主键，性能就会出现断崖式下跌。 - 方言差异要门儿清：像 Oracle 和 SQL Server 支持
WHEN NOT MATCHED BY SOURCE THEN DELETE这种“删多余”的操作，但 PostgreSQL 目前就不支持这个子句，得用DELETE ... USING来配合实现。至于 MySQL，它压根不支持标准 SQL 的MERGE，通常用INSERT ... ON DUPLICATE KEY UPDATE来替代，但语义上并不完全等价，比如无法删除行，也不支持多条件匹配。
ON 子句里不能只写主键，要覆盖业务唯一性
这里有个关键认知：MERGE 的行为完全由 ON 子句定义。它不是在“找主键”，而是在“找逻辑上应该算作同一行的记录”。举个例子，同步订单明细时，如果只靠 order_id 来匹配，那一条订单下的多个商品项就会被错误地合并成一行。所以，必须加上 product_id 或 line_number 这类字段，才能准确反映业务上的唯一性。
条件设得不合适，常见的问题就来了：
- 目标表出现诡异重复行：当
ON条件过宽（比如只用了日期字段），可能导致多条源记录都匹配到同一条目标行，进而触发多次UPDATE，逻辑就乱了。 - 该更新的行却被插入了：反过来，如果
ON条件过严（比如不小心加了一个未经清洗的、值为NULL的字段），就会导致匹配失败，本该更新的记录被当成了新行插入。 - 过滤条件不能放错地方：想对源表做过滤，
WHERE子句必须写在USING部分的子查询里。如果把它放在ON子句外部，可能会引发意想不到的 NULL 匹配，结果难以预料。
UPDATE 和 INSERT 的 SET 子句要区分来源
在 WHEN MATCHED THEN UPDATE SET 这部分，右侧的表达式默认是从源表取值的。但是，如果想引用目标表自身的字段（比如做一个累加操作），就必须显式地加上表别名，否则要么报错，要么逻辑错乱。不同数据库在这点上要求不同：SQL Server 比较严格，要求所有更新列都带上 source. 或 target. 前缀；Oracle 虽然允许省略，但为了清晰和避免歧义，强烈建议写清楚。
来看个 SQL Server 的示例：
MERGE target AS t USING (SELECT id, name, score FROM source WHERE status = 'active') AS s ON t.id = s.id WHEN MATCHED THEN UPDATE SET t.name = s.name, t.score = t.score + s.score -- 注意 t.score 是目标值 WHEN NOT MATCHED THEN INSERT (id, name, score) VALUES (s.id, s.name, s.score);
这里有几个关键点需要特别注意：
- 在
INSERT的VALUES部分，只能引用源表（s.xxx）的字段，引用目标表别名（t.xxx）是语法错误。 - 如果源字段可能为
NULL，而业务上又要求在这种情况下保留目标表原有的值，那就得用COALESCE(s.name, t.name)这样的函数来处理，而不是直接赋值s.name。 - 注意，在 SQL Server 中，
UPDATE SET后面不能直接使用聚合函数或子查询；Oracle 虽然允许，但那么写性能通常会非常差。
执行前务必验证匹配结果，别信“应该只影响 N 行”
必须警惕的是，MERGE 一旦出错，往往就是大面积的误更新或误删除，而且除了回滚整个事务，没有中间状态可挽回。因此，最稳妥的做法就是在正式执行前，先把匹配逻辑验证一遍。别相信“理论上应该只影响N行”这种假设。
具体方法是，把 USING 和 ON 部分单独抽出来，用查询看看匹配关系：
先运行这个，看看哪些行会匹配上并更新：
SELECT 'MATCHED' AS op, s.*, t.* FROM source s INNER JOIN target t ON s.id = t.id AND s.version > t.version;
再补查一下，看看哪些行会被当作新数据插入：
SELECT 'NOT MATCHED' AS op, s.* FROM source s LEFT JOIN target t ON s.id = t.id WHERE t.id IS NULL;
还有一些容易被忽略的“坑”：
- 字符集与排序规则：如果源表和目标表的字符集或排序规则不一致（比如一个大小写敏感，一个不敏感），
ON条件的匹配可能会静默失败，结果和预期不符。 - 统计信息与执行计划：在某些数据库（如老版本的 SQL Server）中，优化器对
MERGE语句的统计信息可能不敏感，即使你加了索引，执行计划也可能不走索引而选择全表扫描。 - 巨大的日志开销：
MERGE产生的事务日志量可能远超你的想象。一次同步10万行，它产生的日志量往往会比同等数量的、独立的UPDATE和INSERT语句大得多，这对日志管理和系统I/O都是个考验。
