oracle merge into语法必须完整包含目标表、on匹配条件、when matched then update和when not matched then insert三部分；on需括号包裹等值判断，insert须显式列名，update后跟set且不可更新on字段。
Oracle MERGE INTO 语法结构怎么写才不出错
MERGE INTO 是 Oracle 唯一原生支持“不存在则插入、存在则更新”的语句，但写错 ON 条件或漏掉 WHEN MATCHED THEN UPDATE / WHEN NOT MATCHED THEN INSERT 分支会直接报错，比如 ORA-00905: missing keyword 或 ORA-00920: invalid relational operator。
核心结构必须完整包含三部分：目标表、匹配条件、两个分支动作。常见错误是把 UPDATE 写成 SET 单独出现，或在 INSERT 子句里漏写列名列表。
-
ON后的条件必须用括号包裹，且只能是等值判断（如t.id = s.id），不支持LIKE或函数表达式（除非两边都加函数且可索引） -
INSERT必须显式列出字段名，不能用*；值来源可以是VALUES(...)或子查询的列 -
UPDATE后必须跟SET，且不能更新ON中用到的关联字段（如SET id = ...会报ORA-00904）
如何避免 MERGE INTO 更新时触发唯一约束冲突
当目标表有唯一索引（如 UNIQUE (email)），而 ON 条件只基于主键 id，但 INSERT 分支插入的 email 已存在，就会抛出 ORA-00001: unique constraint violated —— MERGE 不会自动检测非 ON 字段的冲突。
解决思路不是靠重试，而是提前在 ON 条件中覆盖业务唯一性字段：
- 若业务上
email才是真正唯一标识，就把ON (t.email = s.email)当作匹配条件，而非id - 若必须用
id匹配，又需防email冲突，可在INSERT前加SELECT过滤：用INSERT ... SELECT ... WHERE NOT EXISTS (SELECT 1 FROM target WHERE email = s.email)替代直插 - 不推荐在
MERGE外套EXCEPTION WHEN DUP_VAL_ON_INDEX，因为异常处理开销大，且无法区分是 INSERT 还是 UPDATE 触发的冲突
MERGE INTO 的性能瓶颈在哪？什么时候该换方案
MERGE 的执行计划通常走 MERGE JOIN 或 HASH JOIN，当源数据量大（比如百万行）且 ON 字段无索引时，性能会断崖下跌——它本质是先做一次全表关联，再分发操作，不是逐行判断。
以下情况建议放弃 MERGE，改用更可控的方式：
- 目标表有触发器：MERGE 可能绕过某些行级触发器逻辑，尤其
FOR EACH ROW触发器对批量操作行为不一致 - 需要部分字段更新（比如只更新
status，但UPDATE分支里写了所有字段）：MERGE 要求SET列表明确，没法像应用层那样动态拼字段 - 源数据来自慢视图或远程 DBLINK：JOIN 阶段会把远端数据全拉到本地再计算，网络和内存压力大；此时先用
CREATE GLOBAL TEMPORARY TABLE缓存源数据更稳
Oracle 12c+ 的 WITH CLAUSE + MERGE 怎么安全复用子查询
想在 MERGE 的 INSERT 和 UPDATE 分支里共用同一份加工后的源数据（比如加了 ROW_NUMBER() 或过滤逻辑），直接写两遍子查询不仅冗余，还可能导致两次执行结果不一致（如含 SYS_GUID() 或 SYSDATE）。
12c 起支持 WITH 子句嵌套 MERGE，但必须注意作用域限制：
-
WITH定义的子查询只能在 MERGE 的USING子句里引用，不能在ON或SET里直接调用别名 - 正确写法是：
MERGE INTO t USING (WITH s AS (SELECT ...) SELECT * FROM s) s ON (t.id = s.id) ... - 如果子查询里用了
SEQUENCE.NEXTVAL，MERGE 执行时仍可能因并行或优化导致跳号，这不是 WITH 的问题，而是序列本身的特性
真正容易被忽略的是：MERGE 的 USING 子句不支持 DML 操作（比如 USING (UPDATE ... RETURNING) 是非法的），所有数据准备必须是纯 SELECT。
