Oracle首选MERGE INTO替代UPDATE...FROM，因其优化器能合理选择驱动表、避免重复扫描，实测150万行更新从30分钟降至8–10秒；需注意ON子句仅放关联条件、业务过滤移至UPDATE WHERE、确保索引覆盖及统计信息新鲜。
Oracle 不支持标准 SQL 的 UPDATE ... FROM 语法，硬写会直接报 ORA-00933: sql command not properly ended；而用子查询形式的 UPDATE（即 SET col = (SELECT ...)）在多表关联更新时，极易触发嵌套循环、重复扫描目标表，执行计划里常出现 B1（表示被驱动表被反复访问），小数据量尚可，一旦源表或目标表超 10 万行，耗时往往从秒级跳到分钟级。
为什么 MERGE INTO 是首选方案
MERGE INTO 是 Oracle 原生“查改合一”操作，优化器能基于统计信息合理选择驱动表、避免全表扫描重复执行，且逻辑隔离清晰（WHEN MATCHED THEN UPDATE 和 WHEN NOT MATCHED THEN INSERT 分开控制）。实测中，对 5k 行小表关联 150w 行大表更新，MERGE INTO 耗时从 30 分钟压至 8–10 秒。
- 必须显式写
WHEN NOT MATCHED THEN NULL或省略该分支——但省略后语义不完整，后续若误加INSERT逻辑，可能破坏业务一致性 - 它天然支持并行：启用前执行
ALTER SESSION ENABLE PARALLEL DML，再在USING子句中加PX提示（如/*+ PARALLEL(t2,4) */） - 不依赖绑定变量，但要求
ON关联字段在源表和目标表上都有匹配索引，否则仍会退化为全表扫描
ON 子句里混业务条件是高频翻车点
典型错误写法：ON (t1.id = t2.id AND t2.status = 'ACTIVE')。这会导致 t2.status = 'ACTIVE' 这类过滤被当作匹配前提，而非更新条件——结果是：本该更新的行因 t2 不满足状态而完全不进入 WHEN MATCHED 分支。
- 正确做法：纯关联放
ON，业务过滤移至UPDATE SET ... WHERE，例如UPDATE SET t1.val = t2.val WHERE t2.status = 'ACTIVE' -
ON中用了函数（如UPPER(t1.code) = UPPER(t2.code)）→ 索引失效，应建函数索引或提前清洗字段 - 字段类型不一致（如
VARCHAR2对CHAR）→ 隐式转换导致索引失效，统一类型再试 - 源表存在重复关联键（如多个
t2.order_id对应同一t1.order_id）→ 触发ORA-30926: unable to get a stable set of rows，必须用ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...)去重
大批量更新卡顿，光靠 MERGE INTO 还不够
当目标表行数超千万、单次 MERGE INTO 执行时间仍超 2 分钟，Undo/Redo 压力、锁竞争、Buffer Cache 淘汰都会成为瓶颈。
- 分批控制：在
USING子句中加WHERE ROWNUM ，配合 PL/SQL 循环提交，每次提交后 <code>DBMS_LOCK.SLEEP(0.1)缓解日志争用 - 临时禁用非关键索引和触发器：更新前
ALTER INDEX idx_name UNUSABLE，更新后ALTER INDEX idx_name REBUILD；触发器同理，但需确认业务无强依赖 - 若更新覆盖表中大部分数据（>30%），考虑 CTAS 替换：用
CREATE TABLE new_t AS SELECT ...构建新表，再RENAME切换，配合NOLOGGING可大幅减少 Redo - 分区表优先走
PARTITION交换：只更新某几个分区时，创建含更新数据的新分区，再EXCHANGE PARTITION，毫秒级完成
真正容易被忽略的是：MERGE INTO 的性能天花板不只取决于 SQL 写法，更取决于统计信息是否新鲜、索引是否覆盖所有关联与过滤字段、以及目标表是否被其他长事务阻塞。跑之前先 EXEC DBMS_STATS.GATHER_TABLE_STATS，比调十遍 SQL 更管用。
