MERGE在Oracle中仅当ON条件能充分利用唯一约束索引时才高效；否则易退化为全表扫描并引发锁争用，应避免函数索引未启用或PL/SQL循环逐行执行。
merge 语句在 oracle 中不是“万能 upsert”，它只在满足特定条件时才真正高效；盲目套用 pl/sql 循环 + merge 反而比单条 merge 慢一个数量级。
什么时候该用 MERGE，而不是 INSERT + UPDATE 分开写
核心判断依据是：目标表是否有唯一约束（PRIMARY KEY 或 UNIQUE 约束）能被 ON 子句中的条件充分利用。如果 ON 条件无法走索引（比如用了函数、模糊匹配、列类型隐式转换），Oracle 会退化为全表扫描 + 哈希连接，此时 MERGE 不仅不快，还更容易触发锁争用。
- ✅ 推荐场景：源数据量大（>10k 行），目标表有
id字段的UNIQUE INDEX，且ON (t.id = s.id)直接命中索引 - ❌ 避免场景：
ON (UPPER(t.name) = UPPER(s.name))—— 函数索引未创建或未启用，执行计划里出现FULL TABLE SCAN - ⚠️ 注意：
MERGE的USING子句不支持直接写子查询带聚合（如SELECT id, COUNT(*) FROM ... GROUP BY id），必须包装成内联视图或临时表，否则报ORA-00904: "invalid identifier"
MERGE 里 WHEN MATCHED THEN UPDATE 的坑
更新逻辑看似简单，但实际最容易出错的是字段覆盖和空值处理。Oracle 默认不会跳过 NULL 值更新 —— 如果源数据某列为 NULL，UPDATE 会把它写进目标表，覆盖原有非空值。
- 显式排除 NULL：写成
UPDATE SET t.col = s.col WHERE s.col IS NOT NULL - 避免意外覆盖：不要依赖
UPDATE的默认行为，所有需要保留原值的字段，必须在SET列表中明确写出，例如t.status = NVL(s.status, t.status) - 性能提示：在
UPDATE分支里加WHERE条件（如WHERE s.updated_at > t.updated_at）能显著减少实际更新行数，但注意该WHERE是作用于匹配后的行，不是过滤USING数据源
PL/SQL 中调用 MERGE 的正确姿势
别把 MERGE 塞进 FOR rec IN (...) LOOP 里逐行执行 —— 这等于放弃批量优势，每次循环都触发一次解析+执行+日志写入。真正高效的做法是让 MERGE 一次性处理整个集合。
- ✅ 正确方式：用集合绑定（
BULK COLLECT+FORALL）构造中间表或全局临时表（GTTS），再对 GTT 执行单条MERGE - ✅ 替代方式：用
WITH子句拼接源数据，例如USING (WITH src AS (SELECT ... FROM DUAL UNION ALL SELECT ...) SELECT * FROM src) - ❌ 错误方式：
FOR i IN 1..tab.COUNT LOOP EXECUTE IMMEDIATE 'MERGE INTO ... VALUES ('||tab(i).id||', ...)' END LOOP;—— 动态 SQL 解析开销爆炸，且无法利用绑定变量缓存 - ⚠️ 注意：
MERGE在 PL/SQL 块中执行时，若涉及自治事务（AUTONOMOUS_TRANSACTION），必须确保COMMIT/ROLLBACK明确，否则可能造成子事务未提交而主事务已回滚，留下脏数据
为什么加了 LOG ERRORS 还是卡住
LOG ERRORS INTO 能捕获违反约束的记录，但它不能绕过锁等待或一致性读问题。如果 MERGE 过程中某行正在被其他会话更新且未提交，你的 MERGE 会卡在 enq: TX - row lock contention，哪怕开了错误日志也一样。
- 先查阻塞源：
SELECT blocking_session, event, seconds_in_wait FROM v$session WHERE sid = &your_sid -
LOG ERRORS只捕获 DML 级错误（如ORA-00001,ORA-01400），不捕获锁等待、超时（ORA-00060）、资源不足（ORA-01652）等运行时异常 - 大批量合并前，建议加
SELECT FOR UPDATE SKIP LOCKED预检关键行，或拆分批次（用ROWNUM BETWEEN x AND y控制每次最多 5000 行），降低锁粒度
真正影响 MERGE 效率的，从来不是语法多难记，而是 ON 条件是否走索引、源数据是否已去重、目标表有没有高水位线（HWM）导致大量空块扫描 —— 这些细节在执行计划里藏得深，但一查就露馅。
