merge在oracle存储过程中高效与否取决于数据源组织、on条件设计、null处理及并发控制；错误地将merge置于for loop中会导致每行重复解析，而正确做法是bulk collect+forall或with子句一次性批量执行。
merge 在 oracle 存储过程中不是“写了就能高效”，关键看你怎么组织数据源、怎么写 on 条件、怎么处理 null 和并发。直接套用单行 using (select ... from dual) 模式在批量场景下反而比 insert/update 分开还慢。
存储过程里别用 FOR LOOP 套 MERGE
常见错误是把 MERGE 放进游标循环里，比如：
FOR rec IN (SELECT id, name FROM src) LOOP MERGE INTO t USING (SELECT rec.id id, rec.name name FROM DUAL) s ON (t.id = s.id) ... ; END LOOP;
这等于每行都触发一次 SQL 解析、执行计划生成、日志写入 —— 批量 10k 行可能耗时秒级，而单条 MERGE 处理同样数据只要毫秒级。
- ✅ 正确做法：先用
BULK COLLECT把源数据读进集合，再用FORALL+ 全局临时表（GTT）或WITH子句一次性喂给MERGE - ✅ 更轻量替代：用
USING (WITH src AS (SELECT * FROM your_source_view) SELECT * FROM src)，避免建 GTT - ❌ 避免动态拼接：
EXECUTE IMMEDIATE 'MERGE ... ' || rec.id—— 绑定变量失效，硬解析爆炸
ON 条件必须能走索引，否则 MERGE 变全表扫描
MERGE 的性能瓶颈几乎总卡在 ON 子句。Oracle 不会为函数表达式自动走索引，比如：
ON (UPPER(t.name) = UPPER(s.name))
即使你建了函数索引，也要确认它被启用且统计信息最新；否则执行计划里会出现 FULL TABLE SCAN + HASH JOIN，吞吐量断崖下跌。
- ✅ 安全写法：
ON (t.id = s.id)，且t.id有UNIQUE INDEX或主键 - ✅ 复合键也行：
ON (t.org_id = s.org_id AND t.tenant_code = s.tenant_code)，但两个字段都得在同一个唯一约束里 - ❌ 别写
ON (t.code = TRIM(s.code))—— 没函数索引就等于放弃索引 - ⚠️ 注意 NULL：
t.id = s.id在任一为NULL时结果为UNKNOWN，匹配失败。源数据要提前WHERE s.id IS NOT NULL
UPDATE 分支必须显式控制 NULL 覆盖
Oracle MERGE 的 UPDATE 默认不跳过 NULL —— 如果源数据某列为 NULL，目标表对应字段就会被清空，这是线上事故高发点。
- ✅ 显式排除：
UPDATE SET t.name = s.name WHERE s.name IS NOT NULL - ✅ 保留原值：
t.status = NVL(s.status, t.status)，而不是只写s.status - ✅ 增量更新（减少实际修改行）：
UPDATE SET t.updated_at = SYSDATE WHERE s.updated_at > t.updated_at—— 这个WHERE是作用于已匹配的行，不是过滤源数据 - ❌ 别依赖“没传就不更新”：Oracle 没默认行为，所有字段都要在
SET里列明
USING 子句不能直接写聚合查询
想基于汇总结果做 Upsert？比如按用户 ID 统计订单数再写回用户表 —— 直接写：
USING (SELECT user_id, COUNT(*) cnt FROM orders GROUP BY user_id) s
会报 ORA-00904: "invalid identifier"，因为 USING 后面的子查询在语法解析阶段不支持裸聚合。
- ✅ 正确包装：
USING (SELECT user_id, cnt FROM (SELECT user_id, COUNT(*) cnt FROM orders GROUP BY user_id)) s - ✅ 或用内联视图别名：
USING (SELECT user_id, cnt FROM (SELECT user_id, COUNT(*) cnt FROM orders GROUP BY user_id) sub) s - ✅ 更推荐方式：先写入 GTT 或用
WITH提前算好，再MERGE—— 语义清晰，调试方便 - ❌ 别在
USING里嵌套太深，Oracle 12c+ 对嵌套层级敏感，容易触发解析异常
真正难的不是语法，是让 ON 条件稳定命中索引、让源数据结构适配批量执行、以及在 UPDATE 里守住 NULL 边界 —— 这三点漏掉任意一个，MERGE 就从优化变成隐患。
