MERGE INTO 的 USING 子句必须接可扫描的行集，如带别名的内联视图或 WITH 构造的干净数据集；直接嵌套未命名、缺 GROUP BY 或在 WHERE 中引用分析函数别名的子查询将报错。
MERGE INTO 本身不支持直接在 USING 子句里写多层嵌套子查询（尤其带聚合或分析函数时），但你可以用 WITH 子句或内联视图包装好逻辑，再喂给 MERGE —— 否则会报 ORA-00904: invalid identifier 或 ORA-00936: missing expression。
USING 后必须是“可扫描的行集”，不能是未命名的复杂子查询
Oracle 要求 USING 后跟一个表、视图，或带别名的子查询（即“内联视图”）。如果你直接写 USING (SELECT ... FROM ...) 却没给它起别名，语句会失败；更常见的是，你在子查询里用了 ROW_NUMBER()、LAG() 或聚合后没 GROUP BY，MERGE 执行时找不到列引用上下文。
- ✅ 正确写法：
USING (SELECT id, MAX(value) AS latest_val FROM src GROUP BY id) s - ❌ 错误写法：
USING (SELECT id, MAX(value) FROM src)（缺别名 + 缺 GROUP BY） - ⚠️ 高危写法：
USING (SELECT id, value, ROW_NUMBER() OVER(PARTITION BY id ORDER BY ts DESC) rn FROM src WHERE rn = 1)（rn在 WHERE 中不可见）
用 WITH 提前构造干净源数据，避免 MERGE 内部逻辑臃肿
当同步逻辑涉及去重、取最新、跨表关联或条件过滤时，硬塞进 USING 会让 MERGE 变得难读、难调、难复用。把清洗逻辑提前放在 WITH 里，既符合 Oracle 19c 对 CTE 的完整支持，也能让 ON 和 WHEN MATCHED 更聚焦于业务规则。
- 比如同步员工数据，只取每个
employee_id最新一条更新记录：WITH latest_updates AS ( SELECT employee_id, new_email, new_salary, last_updated, ROW_NUMBER() OVER (PARTITION BY employee_id ORDER BY last_updated DESC) rn FROM emp_staging ) MERGE INTO employees e USING (SELECT * FROM latest_updates WHERE rn = 1) u ON (e.employee_id = u.employee_id) WHEN MATCHED THEN UPDATE SET e.email = u.new_email, e.salary = u.new_salary WHEN NOT MATCHED THEN INSERT (employee_id, email, salary, hire_date) VALUES (u.employee_id, u.new_email, u.new_salary, SYSDATE); -
WITH中的子查询可加索引提示、物化提示（/*+ MATERIALIZE */），而 MERGE 内部的子查询无法加
ON 条件里别依赖子查询结果列，匹配必须基于物理/计算列
ON 子句是 MERGE 的“判断开关”，它必须能被优化器转为等值连接谓词。如果你在 ON 里写 e.id = (SELECT MAX(id) FROM ref WHERE ...) 这类标量子查询，Oracle 会拒绝执行（报 ORA-00936）；即使允许，也会导致全表扫描目标表，性能归零。
- ✅ 安全做法：所有匹配字段都来自
USING子句输出的列，且目标表上有对应索引（如e.employee_id） - ❌ 危险操作：
ON (e.id = (SELECT id FROM temp_control WHERE batch = '202609')) - ? 替代方案：把控制参数提前查出来，拼成绑定变量传入；或用
USING关联该控制表（如USING (SELECT ... FROM emp_staging s JOIN batch_config c ON ...) u）
真正卡住人的从来不是 MERGE 语法本身，而是你往 USING 里塞的那块“数据”是否真的可定位、可索引、可预测 —— 它得像一张表一样规整，而不是一段需要运行时解析的逻辑。先让源数据立住，MERGE 才能稳。
