merge是sql server和oracle中实现upsert最原子、最可控的方式，但必须同时满足匹配逻辑（on基于非null唯一键）、分支完整性（when matched和when not matched均不可省）、并发保护（批量用临时表+holdlock）三重条件。
MERGE 是 SQL Server 和 Oracle 中实现 Upsert 最原子、最可控的方式，但写错一个分支或漏锁就会 silently 失败或死锁——它不是“语法对就能用”，而是必须同时满足匹配逻辑、分支完整性、并发保护三重条件。
WHEN MATCHED 和 WHEN NOT MATCHED 都不能省
SQL Server 强制要求 MERGE 必须显式写出 WHEN MATCHED THEN UPDATE 和 WHEN NOT MATCHED THEN INSERT 两个分支。漏掉任一个直接报错：Incorrect syntax near the keyword 'MERGE' 或更隐蔽的 The MERGE statement attempted to UPDATE or DELETE the same row more than once。
- 即使业务上只做插入（比如日志归档），也要补上
WHEN MATCHED THEN UPDATE SET @dummy = @dummy这类空操作 - Oracle 允许只写一个分支，但 SQL Server 不行；别指望跨数据库兼容
- PostgreSQL 和 MySQL 根本不用 MERGE，它们走
INSERT ... ON CONFLICT或INSERT ... ON DUPLICATE KEY UPDATE，语法更轻量
ON 条件必须基于非 NULL 唯一键，且目标表要有唯一索引
ON t.id = s.id 看似简单，但若 id 列允许 NULL，该条件在任一为 NULL 时恒为 UNKNOWN，导致所有行都落入 WHEN NOT MATCHED 分支——结果就是重复插入，主键冲突。
- 务必提前过滤源数据：
WHERE id IS NOT NULL，别依赖 ON 子句兜底 - 目标表的匹配列（如
id）必须是主键，或至少有唯一索引；否则可能触发多匹配错误 - 避免在 ON 中用函数，比如
UPPER(t.email) = UPPER(s.email)，会绕过索引，批量时性能断崖下跌
批量 Upsert 必须用临时表 + HOLDLOCK，别逐行调用
用 Python 循环执行单行 MERGE，在千行以上就明显变慢；真正高效的做法是把数据先批量载入临时表，再单次 MERGE 处理全集。
- 建本地临时表：
CREATE TABLE #staging (id INT, name NVARCHAR(50), score INT)，并在id上建索引：CREATE INDEX IX_staging_id ON #staging(id) - 用
SqlBulkCopy或bcp批量灌入数据，比executemany快 10–100 倍 - 高并发场景下，必须加
WITH (HOLDLOCK)锁提示：MERGE INTO users WITH (HOLDLOCK) AS t USING #staging AS s ON t.id = s.id
UPDATE 不自动跳过无变化字段，想避免无意义更新得手动加 WHERE
WHEN MATCHED THEN UPDATE SET name = s.name, score = s.score 只判断 ON 是否成立，不比较字段值是否真有变化——哪怕新旧值完全一样，也会触发一次 UPDATE，影响 updated_at、触发器、CDC 日志等。
- SQL Server 不允许在
WHEN MATCHED后直接跟AND t.score != s.score；正确做法是在UPDATE SET中用CASE或在语句外加WHERE子句（需改用子查询包装源数据） - Oracle 允许在
WHEN MATCHED后加AND条件，但执行计划稳定性差，2019+ 版本优化有限 - PostgreSQL 的
ON CONFLICT ... DO UPDATE支持WHERE，更适合控制更新时机
最容易被忽略的是：MERGE 的原子性只保证语句内逻辑不中断，不等于业务上“一定成功”。源数据重复、目标表约束变更、锁升级失败都会让整条语句回滚——别把它当黑盒，每次上线前必须用真实数据量 + 并发压测验证锁行为和执行计划。
