ORA-30926错误源于ON条件无法建立一对一映射，ROW_NUMBER() OVER(PARTITION BY...)通过分组排序强制每组单行解决；需替换key_col1,key_col2为ON字段，避免非确定性函数，推荐用ON COMMIT DELETE ROWS临时表确保稳定性。
ORA-30926 错误不是数据没更新成功，而是 Oracle 在解析阶段就拒绝执行——它发现 USING 子句返回的行集无法与 ON 条件建立一对一映射关系，直接中止。
为什么 ROW_NUMBER() OVER(PARTITION BY ...) 是最常用解法
Oracle 要求每个目标键（ON 中的字段组合）最多对应一条源行。当源表天然存在重复（比如日志表按 user_id + event_type 多次记录），就必须显式选一条。
-
ROW_NUMBER()能在子查询里强制“每组只留一行”，且排序字段（如create_time DESC）决定业务语义（取最新/最早） - 不能只写
WHERE ROWNUM ——没 <code>ORDER BY时结果非确定，仍会触发 ORA-30926 - 别用
MAX()聚合后丢掉其他字段：如果需要status或source_id等非聚合列，聚合会报错或丢失信息
示例：USING (SELECT user_id, status, source_id FROM (SELECT user_id, status, source_id, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY update_time DESC) rn FROM log_table) WHERE rn = 1)
USING 子查询里用 ROWID 去重的风险点
有人用 WHERE t.ROWID = (SELECT MAX(y.ROWID) FROM tab y WHERE y.id = t.id) 去重，看似简单，但隐患明显：
- ROWID 不是业务主键，同一逻辑记录可能因迁移、导出导入产生多个 ROWID
- 高并发下，两次子查询读到不同 ROWID 快照，导致“匹配时选 A，更新时找 B”，仍可能失败
- 索引组织表（IOT）或启用压缩的表，ROWID 可能无效或不唯一
除非你 100% 确认源表无迁移、无 IOT、且无并发写入，否则优先用带明确业务排序的 ROW_NUMBER()。
MERGE 执行前如何快速验证源行稳定性
别等跑 MERGE 报错才排查。执行前用这条 SQL 检查 USING 子查询是否满足一对一约束：
SELECT key_col1, key_col2, COUNT(*) FROM (your_using_subquery) GROUP BY key_col1, key_col2 HAVING COUNT(*) > 1
- 把
key_col1, key_col2替换成你ON条件里的所有字段 - 如果返回任何行，说明该子查询必然触发 ORA-30926
- 注意：这个查询本身也必须稳定——避免在子查询里用
SYSDATE、DBMS_RANDOM等非确定性函数
临时表比复杂子查询更可靠
当 USING 子查询嵌套深、含多个 JOIN 或窗口函数时，优化器可能无法准确推导行唯一性，即使逻辑上已去重，仍报 ORA-30926。
- 把清洗后的结果 INSERT INTO GLOBAL TEMPORARY TABLE（GTT），再
USING这张 GTT - GTT 的统计信息可控，且 Oracle 对物理表的唯一性判断更保守可靠
- 记得加
ON COMMIT DELETE ROWS，避免事务残留
真正麻烦的不是语法怎么写，而是你得确认那个“稳定”是业务可接受的稳定——比如选最新一条，是否真代表当前有效状态？还是该合并多条的累计值？这一步漏判，后面数据就歪了。
