ORA-01779错误的根本原因是Oracle要求UPDATE子查询中被修改的表必须是“键值保存表”（key-preserved），即其主键或唯一键在JOIN结果中必须一一对应原行；若关联表存在一对多关系（如t2有多行匹配t1一行），则t1不再满足键值保存，更新被拒绝。
为什么子查询UPDATE在Oracle里容易报ORA-01779错误
当你写 UPDATE (SELECT ... FROM t1 JOIN t2 ON ...) SET ... 这类语句时，Oracle常抛出 ORA-01779: cannot modify a column which maps to a non key-preserved table。根本原因不是语法错，而是Oracle要求被更新的表（比如t1）在JOIN结果中必须是“key-preserved”——即t1的主键/唯一键在结果集中不重复、可明确映射回原行。一旦t2有多条记录匹配t1的一行，这个条件就崩了。
常见踩坑场景：
• 用左连接更新主表，但关联表有冗余数据
• 在视图或复杂JOIN结果上直接UPDATE
• 误以为“能SELECT就能UPDATE”
MERGE INTO怎么绕过key-preserved限制
MERGE INTO 不依赖JOIN结果的可更新性，它把“匹配逻辑”和“更新动作”拆开：先用 ON 条件定位目标行，再用 WHEN MATCHED THEN UPDATE 执行修改。只要 ON 能唯一确定源数据行（比如用主键或唯一组合），就不会触发ORA-01779。
实操要点：
• ON 子句必须包含目标表的主键或唯一约束字段，避免一对多匹配
• 源数据建议来自SELECT子查询，而非直接JOIN表（更易控制去重）
• 如果源数据可能为空，加 WHEN NOT MATCHED THEN INSERT 可选，但批量更新通常只用 WHEN MATCHED
示例：用订单明细更新订单主表状态
MERGE INTO orders o USING ( SELECT DISTINCT order_id, 'SHIPPED' AS new_status FROM order_items WHERE quantity > 10 ) src ON (o.order_id = src.order_id) WHEN MATCHED THEN UPDATE SET o.status = src.new_status;
MERGE INTO比UPDATE子查询快在哪
Oracle对 MERGE INTO 有专门优化：一次全表扫描完成匹配+更新，而子查询UPDATE可能触发嵌套循环（尤其带WHERE的关联子查询），导致目标表被反复扫描。
性能关键点：
• ON 字段必须有索引（通常是目标表主键，天然有索引）
• 源查询（USING部分）如果复杂，先物化为临时表或加提示（如 /*+ MATERIALIZE */）
• 避免在 ON 中用函数，比如 ON (UPPER(o.code) = src.code) 会失效索引
对比场景：更新10万行，关联表50万行。实测 MERGE INTO 耗时通常比等效子查询UPDATE低30%~60%，差异主要来自执行计划里少了FILTER操作和重复访问。
实际用MERGE要注意的硬约束
Oracle对 MERGE INTO 有几条铁律，违反直接报错：
• 目标表不能是远程表（@dblink）、视图、物化视图日志表
• ON 条件中不能出现聚合函数、分析函数、ROWNUM
• 更新列不能是虚拟列（除非是基于确定性表达式的）、标识列（IDENTITY）
• 如果目标表有启用的BEFORE/AFTER ROW触发器，MERGE 仍会触发，但触发器里不能用 :OLD 和 :NEW 访问未被修改的列（这点常被忽略）
最易漏的细节：当源查询返回重复 order_id 时，MERGE 会报 ORA-30926: unable to get a stable set of rows in the source tables。必须确保 USING 子查询对 ON 字段是唯一映射——加 DISTINCT 或 GROUP BY 是最低成本解法。
