MERGE语句报错时，很多人第一反应是语法写错了，或者表结构不匹配。其实，根本原因往往藏在源数据的“隐秘角落”——用于ON条件的字段里出现了重复值。一旦源表某条关联键对应多个行，数据库就面临一道无法抉择的选择题：哪个源行才是目标行应该匹配的？于是直接抛出ORA-30926或类似错误，拒绝执行这种模糊操作。

简而言之：MERGE语句的“稳定行”校验机制，要求每个目标行必须对应唯一确定的源行。一旦源表里ON字段出现重复（比如两个订单记录共用一个order_id），这个前提就被打破了。

源表ON字段重复直接触发“稳定行”校验失败

数据库执行MERGE时，第一阶段必须为每个目标行确定唯一对应的源行。一旦源表中ON子句所用字段（比如order_id、customer_code）出现重复，就形成一对多映射。此时引擎无法判断该用哪条源记录更新目标行，立刻抛出类似ORA-30926或Cannot obtain a stable set of rows的错误。

• 常见场景：上游系统推送数据未去重，如两个交易记录共用同一transaction_id
• 容易忽略点：重复可能来自NULL值——多数数据库把多个NULL视为相等，也会触发该错误
• SQL Server报错提示更直白：The MERGE statement attempted to UPDATE or DELETE the same row more than once

MySQL和PostgreSQL不支持标准MERGE，误用INSERT ... ON DUPLICATE KEY UPDATE会掩盖问题

MySQL没有MERGE关键字，常用INSERT ... ON DUPLICATE KEY UPDATE模拟。但它只按主键/唯一键冲突触发更新，不校验源数据是否重复——表面成功，实际可能用最后一条重复记录覆盖前面的正确值，造成静默数据污染。

• PostgreSQL用INSERT ... ON CONFLICT，同样跳过源端去重检查
• 真正需要MERGE语义时（比如带DELETE分支），必须手动拆解为UPDATE+INSERT+DELETE，但要额外加NOT EXISTS或临时表去重
• Druid连接池+MySQL环境下报merge sql error，大概率是误写了MERGE关键字而非适配MySQL语法

修复必须前置：在USING子句里做源数据排重，而不是靠目标表约束兜底

有人试图在目标表加唯一索引，指望数据库在INSERT时报错再回滚——这完全无效。MERGE的“稳定行”校验发生在DML执行前，约束冲突根本不会触发。

• 正确做法：把源表包装成CTE或子查询，用ROW_NUMBER() OVER (PARTITION BY join_key ORDER BY ...)标记重复，并只取rn = 1的行
• 若业务逻辑允许合并（如取最新时间戳那条），ORDER BY后明确指定优先级字段；若不允许合并，应提前拦截并告警
• ODBC场景下还可能因数值精度传递失真导致ON条件误判为不匹配，此时需在SQL中显式CAST，例如ON t.target_col = s.source_col::numeric(10,2)

真正棘手的不是怎么写MERGE，而是怎么证明源数据在关联键上确实无重复——这往往要追溯到上游ETL清洗逻辑，或者API调用方的数据生成规则。一旦漏掉这个验证环节，再漂亮的MERGE语句也只是定时冲击波。