子查询是MERGE INTO实现增量同步的必需核心组件；因其必须在USING中完成去重、增量过滤和字段补全，否则将引发ORA-30926错误或数据错漏。
子查询不是MERGE INTO的可选配件，而是它处理增量逻辑的核心载体；直接用表名做USING几乎必然出错。
为什么MERGE INTO必须搭配子查询才能做增量同步
因为真实增量场景中，源数据从来不是“原样拿来就能用”的静态快照。你需要在进入MERGE之前就完成去重、过滤、取最新、补缺字段等操作——这些都只能在USING后的子查询里完成。直接写USING source_table等于把脏数据、重复键、过期版本一股脑喂给MERGE，轻则ORA-30926报错，重则更新错行、漏同步、主键冲突。
- 源表可能含多条同一业务主键的变更记录（比如订单被改了三次），但目标表只该存最后一次
- 增量抽取可能只拿到时间范围内的原始日志，需按业务键聚合后才能用于匹配
- 某些字段在源表里是空的，需在子查询中用
NVL或CASE补默认值，否则INSERT时违反NOT NULL约束
子查询里必须解决的三个关键问题
一个能进生产环境的增量MERGE，其USING子查询至少要同时应对这三类问题：
-
唯一性保障：对ON条件中使用的字段（如
ORDER_ID），必须确保子查询结果里每值只出现一次。常用手段是ROW_NUMBER() OVER (PARTITION BY ORDER_ID ORDER BY LAST_UPDATE_DATE DESC)+WHERE rn = 1 -
增量边界控制：不能无条件拉全量。典型做法是关联控制表：
WHERE o.LAST_UPDATE_DATE > (SELECT LAST_SYNC_TIMESTAMP FROM ETL_CONTROL WHERE JOB_NAME = 'ORDER_SYNC') -
字段对齐与补全：子查询SELECT列表必须包含所有
WHEN MATCHED THEN UPDATE SET和WHEN NOT MATCHED THEN INSERT需要的列，且类型兼容。例如目标表有ETL_LOAD_TIME DATE NOT NULL，子查询就得显式写SYSDATE AS ETL_LOAD_TIME
ORA-30926报错的直接原因和修复路径
这个错误信息unable to get a stable set of rows in the source tables本质就是Oracle在执行阶段发现：对目标表某一行，USING子查询返回了多行满足ON条件的数据。它无法决定该用哪一行去更新。
- 最常见诱因：子查询没去重，比如
USING (SELECT * FROM SOURCE_ORDERS WHERE ...)，而源表本身存在重复ORDER_ID - 容易被忽略的陷阱：子查询里用了
JOIN，但没意识到关联表有1:N关系，导致源数据被放大（例如订单表JOIN订单明细表，一条订单变多行） - 修复动作必须落在子查询内部：加
DISTINCT、加GROUP BY、或用窗口函数筛出唯一行；绝不能指望在ON条件里加额外谓词来“绕开”
性能卡点往往藏在子查询的执行计划里
千万级数据下，MERGE慢，90%的问题不在MERGE本身，而在USING子查询没走索引、没做分区裁剪、或产生了大量临时排序。
- 检查子查询是否对过滤字段（如
LAST_UPDATE_DATE）有有效索引；没有就建，别依赖MERGE的“智能” - 如果源是分区表，确保WHERE条件能触发分区裁剪，例如用
AND PARTITION_KEY >= TO_DATE('20260510', 'YYYYMMDD') - 避免子查询中出现
SELECT *，只取MERGE真正需要的列；尤其不要带LOB或长文本字段，它们会拖慢整个中间结果集 - 测试时先单独跑
SELECT COUNT(*) FROM (your USING subquery)，确认结果集大小合理（比如预期10万行，却扫出500万行，说明过滤逻辑错了）
子查询不是MERGE的装饰性语法糖，它是你掌控增量逻辑精度的唯一操作面。写完MERGE语句后不验证子查询的唯一性、边界性和执行效率，等于把同步任务交给运气。
