MERGE INTO 并非万能，其安全执行需源数据主键唯一且匹配条件明确；否则因无法确定更新行而报错，如ORA-30926或SQL Server的重复更新错误。
MERGE INTO 不是万能的“自动更新开关”，它只在匹配条件唯一、源数据干净的前提下才能安全执行主键冲突处理；否则直接报错，比如 ORA-30926 或 SQL Server 的“attempted to UPDATE the same row more than once”。
为什么 MERGE INTO 会因主键冲突直接失败
根本原因不是目标表主键重复，而是源表里同一主键值出现多次 —— 这导致数据库无法确定该用哪一行去更新目标行。例如源表有两条 order_id = 'ORD1001' 记录，MERGE 就卡在“到底用哪条更新？”这一步，拒绝执行。
- Oracle 报
ORA-30926: unable to get a stable set of rows in the source tables - SQL Server 报
The MERGE statement attempted to UPDATE or DELETE the same row more than once - PostgreSQL 15+ 在类似场景下也会报错，但错误信息更接近
duplicate key value violates unique constraint（如果 ON 条件没覆盖全约束）
SQL Server 中 MERGE 必须写全 WHEN NOT MATCHED BY TARGET
少写 BY TARGET 三个字，语句就语法错误。这不是可选修饰，而是 SQL Server 强制要求的明确语义：你必须声明“不匹配的是目标表中的行”，否则它无法区分插入和删除逻辑。
- 正确写法：
WHEN NOT MATCHED BY TARGET THEN INSERT ... - 错误写法：
WHEN NOT MATCHED THEN INSERT ...→ 直接报错Incorrect syntax near 'THEN' - 如果还要支持删除（比如源表中不存在但目标表中已过期的记录），得额外加
WHEN NOT MATCHED BY SOURCE THEN DELETE
源表去重必须在 USING 子句里完成，不能靠业务层保证
别信“上游说数据不重复”。MERGE 执行时只看当前传入的源数据快照，它不会帮你查重或选优。必须显式用 ROW_NUMBER() 或 DISTINCT 预处理。
- 推荐方式（按时间取最新）：
USING (SELECT id, name, updated_at FROM (SELECT id, name, updated_at, ROW_NUMBER() OVER (PARTITION BY id ORDER BY updated_at DESC) AS rn FROM #staging) t WHERE rn = 1) AS src
- 避免用
GROUP BY简单聚合，除非你明确知道如何处理字符串/日期字段的合并逻辑（比如MAX(name)可能不是你想要的） - 临时表或表变量（如
@staging）比 CTE 更稳定，尤其在存储过程中反复调用时
UPDATE 和 INSERT 字段必须满足非空约束，且类型兼容
看起来只是写 SQL，但漏掉一个 NOT NULL 字段或传了 NULL 给不允许为空的列，就会在 INSERT 分支失败，而 UPDATE 分支可能成功 —— 导致部分数据写入、部分报错，事务回滚与否取决于你是否显式包装了 BEGIN TRY / CATCH。
- 检查目标表 DDL：
SELECT column_name, is_nullable, data_type FROM sys.columns WHERE object_id = OBJECT_ID('your_table') - INSERT 分支的
VALUES列表里，每个字段都得有值，或确保默认值可用（比如GETDATE()、NEWID()） - UPDATE 分支若引用
EXCLUDED.*（PostgreSQL）或source.*（SQL Server），要确认这些值不为NULL且类型能隐式转换
真正难的从来不是写对 MERGE 语法，而是让源数据在进入 ON 条件前就“一人一卡”——索引、去重、类型校验、约束对齐，缺一不可。任何环节松动，它就不是自动更新，而是自动报错。
