ora-30926错误的根本原因是using子查询未保证关联键唯一性，导致oracle无法确定用哪条源记录更新目标行；必须用row_number() over(partition by join_key order by ... ) + where rn=1预筛出稳定单行，或提前清理临时表重复数据。
为什么直接在USING里写子查询容易报 ORA-30926
根本原因是 MERGE INTO 要求源表（USING 后的部分）返回「稳定的一行」与目标表匹配。如果子查询没去重、没加排序、又没限制，Oracle 无法确定该用哪条源记录更新目标行，就直接抛 ORA-30926: unable to get a stable set of rows in the source tables。
嵌套查询必须带 row_number() 去重 + 确定排序
不能只写 SELECT * FROM t WHERE ... 就塞进 USING。得先用窗口函数锚定唯一行：
-
ROW_NUMBER() OVER (PARTITION BY join_key ORDER BY update_time DESC)是最常用组合，按业务主键分组、取最新一条 - 必须显式指定
ORDER BY，否则row_number()排序不可控，仍可能不稳 - 外层再套一层
WHERE rn = 1，确保每个join_key最多一条源记录
示例：
MERGE INTO employees e
USING (
SELECT emp_id, name, salary, dept_id
FROM (
SELECT emp_id, name, salary, dept_id,
ROW_NUMBER() OVER (PARTITION BY emp_id ORDER BY last_modified DESC) rn
FROM staging_employees
WHERE status = 'ACTIVE'
)
WHERE rn = 1
) s
ON (e.emp_id = s.emp_id)
WHEN MATCHED THEN
UPDATE SET e.name = s.name, e.salary = s.salary, e.dept_id = s.dept_id
WHEN NOT MATCHED THEN
INSERT (emp_id, name, salary, dept_id) VALUES (s.emp_id, s.name, s.salary, s.dept_id);
别把过滤条件全堆在 ON 或 WHERE 里
ON 只管关联逻辑，USING 子查询里的过滤才真正减少数据量、避免重复风险：
- 错误做法：把
WHERE status = 'ACTIVE'放在WHEN MATCHED THEN UPDATE WHERE ...—— 此时重复已产生，报错早于执行到这步 - 正确做法：过滤写在子查询内部（如上例），让源集本身无歧义
- 如果要按目标表状态跳过某些更新，再在
UPDATE ... WHERE加条件，但那是第二道筛选
临时表有重复？优先 truncate + insert 去重再 merge
如果源是临时表且已存在重复，嵌套查询成本高，不如前置清理：
- 用
DELETE FROM temp_table WHERE rowid NOT IN (SELECT MIN(rowid) FROM temp_table GROUP BY key_col)去重 - 或建新临时表：
CREATE TABLE temp_clean AS SELECT DISTINCT ... FROM temp_table - 再去
USING temp_clean—— 比每次跑row_number()更快，尤其数据量大时
嵌套查询不是万能解药；当源数据本身质量差，靠 SQL 补救不如源头治理——去重和排序逻辑越靠近数据入口，MERGE INTO 越不容易翻车。
