Oracle 19c跨表关联更新首选MERGE INTO语法，因其规避子查询单行限制与NULL赋值风险，但要求ON条件列在源表有唯一性保障；大批量更新须分批提交并收集统计信息。
Oracle 19c 中跨表关联更新不能直接用 JOIN 写在 UPDATE 语句里 —— 这是初学者最常踩的语法坑，一写就报 ORA-00971: missing SET keyword 或 ORA-01779: cannot modify a column which maps to a non key-preserved table。
UPDATE ... SET ... WHERE EXISTS 不适合字段值动态取源表数据
这种写法看似能绕过 JOIN 限制，但只适用于「判断是否存在匹配」后统一赋固定值（比如 status = 'PROCESSED'），一旦你想把源表某字段值赋给目标表，就必须用子查询，而子查询有硬性约束：
- 子查询必须返回**至多一行**，否则报
ORA-01427: single-row subquery returns more than one row - 如果源表中无匹配记录，子查询返回 NULL，目标字段会被设为 NULL —— 即使你加了
WHERE EXISTS，也得额外用NVL或COALESCE包裹，否则可能触发ORA-01407: cannot update (%s) to NULL - 执行计划里，对源表会扫描两次：一次在
SET子查询，一次在WHERE EXISTS，性能打折
示例（危险写法）：
UPDATE employees e SET salary = (SELECT s.new_salary FROM salary_updates s WHERE s.employee_id = e.employee_id) WHERE EXISTS (SELECT 1 FROM salary_updates s WHERE s.employee_id = e.employee_id);
更安全的等效写法（避免 NULL 赋值）：
UPDATE employees e SET salary = NVL((SELECT s.new_salary FROM salary_updates s WHERE s.employee_id = e.employee_id), e.salary) WHERE EXISTS (SELECT 1 FROM salary_updates s WHERE s.employee_id = e.employee_id);
MERGE INTO 是 Oracle 关联更新的首选语法
MERGE INTO 不仅语法清晰、原子性强，还能天然规避子查询单行限制和 NULL 赋值风险。它要求 ON 条件列在源表上**有唯一性保障**（比如主键或唯一索引），否则会报 ORA-30926: unable to get a stable set of rows in the source tables。
- 目标表别名（如
e）必须出现在MERGE INTO后，不能写在USING子句里 -
USING后可以跟表、视图，也可以是带别名的子查询，但子查询结果集必须可稳定映射（即 ON 字段组合在源侧唯一） - 如果只想更新、不插入，就不要写
WHEN NOT MATCHED THEN INSERT分支 - Oracle 19c 支持
UPDATE SET (col1, col2) = (SELECT ...)多列批量赋值，但必须确保 SELECT 返回列数和类型严格匹配
标准用法示例：
MERGE INTO employees e USING salary_updates s ON (e.employee_id = s.employee_id) WHEN MATCHED THEN UPDATE SET e.salary = s.new_salary, e.last_updated = SYSDATE;
大批量关联更新必须分批 + 提交，否则锁死业务
哪怕用了 MERGE INTO，一次性更新 10 万行以上，依然会引发严重问题：UNDO 段暴涨、行锁堆积、其他会话长时间阻塞、甚至 ORA-01555 快照过旧。关键不是换语法，而是拆事务。
- 分批依据优先选主键或唯一索引字段（如
employee_id），避免ROWID因表移动失效 - 每批控制在 1000–5000 行，
COMMIT频率要高，但别每行都提交（太慢） - 务必在关联字段（
ON条件列）上建索引，否则分批也救不了全表扫描 - 执行前先跑
EXPLAIN PLAN确认走的是索引查找（INDEX RANGE SCAN或UNIQUE SCAN），不是FULL TABLE SCAN
PL/SQL 分批模板（可直接改参数复用）：
BEGIN
FOR batch IN (
SELECT MIN(employee_id) low_id, MAX(employee_id) high_id
FROM (
SELECT employee_id,
NTILE(100) OVER (ORDER BY employee_id) grp
FROM salary_updates
)
GROUP BY grp
) LOOP
MERGE INTO employees e
USING (SELECT * FROM salary_updates WHERE employee_id BETWEEN batch.low_id AND batch.high_id) s
ON (e.employee_id = s.employee_id)
WHEN MATCHED THEN
UPDATE SET e.salary = s.new_salary;
COMMIT;
END LOOP;
END;更新后必须手动收集统计信息
Oracle 优化器不会自动感知大批量 DML 后的数据分布变化。如果后续查询性能变差，大概率是执行计划没更新。别跳过这步：
- 只更新一张表？用
DBMS_STATS.GATHER_TABLE_STATS，加cascade => TRUE确保索引统计也刷新 - 关联字段上有直方图（比如
employee_id值分布极不均匀）？显式指定method_opt => 'FOR COLUMNS employee_id SIZE AUTO' - 别依赖
AUTO_SAMPLE_SIZE在大表上抽样——19c 默认采样率可能偏低，导致直方图不准；宁可设estimate_percent => 10手动定采样比例
执行示例：
EXEC DBMS_STATS.GATHER_TABLE_STATS( ownname => 'HR', tabname => 'EMPLOYEES', estimate_percent => 10, method_opt => 'FOR COLUMNS employee_id SIZE AUTO', cascade => TRUE );
真正容易被忽略的点是：MERGE 的 ON 条件列如果没有唯一性约束，错误不会立刻报出，而是在运行时随机失败；分批逻辑若没加 COMMIT，整个 PL/SQL 块仍是一个事务；统计信息不更新，第二天业务慢查询排查时，没人会想到是昨天那条 MERGE 导致的执行计划退化。
