merge into 的 on 条件应仅含关联字段，业务过滤须移至 update where；源表必须去重（防 ora-30926），字段类型与索引需严格对齐，大批量操作须分批、加事务控制及错误捕获。
MERGE INTO 的 ON 条件必须只放关联字段，业务过滤要挪到 UPDATE WHERE 里
很多人把 status = 'ACTIVE' 这类业务条件直接塞进 ON 子句，比如写成 ON (t.id = s.id AND s.status = 'ACTIVE')。这会导致两个问题：一是匹配失败的源行被彻底忽略，哪怕它们本该触发更新；二是如果 s.status 没走索引，整个 ON 匹配会退化为全表扫描。
- 正确做法是把纯关联逻辑留在
ON，例如ON (t.id = s.id) - 业务过滤下移到
UPDATE SET ... WHERE s.status = 'ACTIVE'—— 这个WHERE是对已匹配的每一行单独判断，不影响匹配过程 - 如果源数据来自视图或子查询，确保
status字段在 USING 子句中已明确输出，且值非计算列
源表必须去重，否则 MERGE 直接报 ORA-30926
ORA-30926: unable to get a stable set of rows in the source tables 是 MERGE 最常遇到的错误之一。根本原因是 USING 子句返回了多条相同匹配键的记录（比如两条 id = 100 的行），Oracle 无法确定该用哪条更新目标行。
- 不能依赖上游“保证不重复”，必须在 MERGE 内部兜底
- 推荐用 CTE 预处理：
WITH clean_src AS (SELECT *, ROW_NUMBER() OVER (PARTITION BY id ORDER BY updated_at DESC) rn FROM src_table) MERGE INTO tgt USING clean_src ON (tgt.id = clean_src.id) WHERE clean_src.rn = 1 - 避免在 USING 中直接 JOIN 多张表，容易引入隐式笛卡尔积；优先聚合后再关联
索引和类型必须对齐，否则 ON 条件失效
即使写了 ON (t.code = s.code)，如果 t.code 是 VARCHAR2(10) 而 s.code 是 CHAR(10)，Oracle 会做隐式转换，导致目标表索引无法使用。同理，UPPER(t.code) = UPPER(s.code) 也会让索引失效。
- 检查两边字段类型是否完全一致，包括长度、字符集、是否可为空
- 目标表匹配字段上必须有索引（最好是唯一索引或主键）；源表对应字段也建议建索引，尤其当源表较大时
- 如果必须用函数匹配，考虑建函数索引，而不是在 ON 里硬写函数调用
大批量同步必须分批 + 显式事务 + 错误捕获
一次性跑几十万行的 MERGE，轻则日志爆满、锁升级成表锁，重则阻塞关键业务。Oracle 不会自动帮你分页，得自己控。
- 每批控制在 20–50 行（不是 20–50 万），用
OFFSET / FETCH NEXT或游标分页 - 每个 MERGE 必须包在
BEGIN TRY / BEGIN CATCH（PL/SQL 用EXCEPTION块）里，捕获后记录失败批次和SQLERRM - 禁用目标表上的 AFTER 触发器（除非业务强依赖），否则触发器执行会显著拖慢速度
真正卡住性能的往往不是 MERGE 语法本身，而是 ON 条件没索引、源数据没去重、字段类型不一致这些细节——它们在小数据量时完全不暴露，一上生产就崩。
