ORA-01779报错源于Oracle要求被更新表必须是键值保存表（key-preserved），即其主键/唯一键在JOIN中能唯一映射；若t2无主键/唯一约束、连接为一对多或含聚合/ROWNUM等，即触发该错误。
为什么直接写 UPDATE (SELECT ... FROM t1 JOIN t2 ...) 会报 ORA-01779？
这不是语法错误，而是 Oracle 在执行前就拒绝了语义不安全的操作。核心原因是：视图中参与 JOIN 的表 t2 没有被识别为“键值保存表”（key-preserved table）。简单说，Oracle 要求被更新的列必须能唯一、确定地映射回底层某一行 —— 如果 t2 缺少主键或唯一约束（比如仅靠外键关联但没建索引），或者连接是一对多（t1 一行对应 t2 多行），它就无法保证更新目标的唯一性，直接抛 ORA-01779。
常见踩坑点：
-
t2.id是外键，但没建索引 → Oracle 无法快速确认是否唯一，常判为非 key-preserved - 用了
LEFT JOIN或JOIN但t2侧无唯一约束 → 即使业务上“应该唯一”，Oracle 不认 - 子查询里写了
ROWNUM或聚合函数 → 破坏可更新性
UPDATE INLINE VIEW 要加什么才能跑通？
想用 UPDATE (SELECT ...) 形式，必须让 Oracle 明确知道哪张表是“安全可改”的。最稳妥的做法是确保被更新字段所属的表，在 JOIN 中是 key-preserved 的 —— 也就是它的主键或唯一键完整出现在 SELECT 列表和 ON 条件中。
实操建议：
- 给
t2的关联字段（如t2.t1_id）建唯一索引或主键，且该字段必须出现在SELECT子句中（哪怕只是别名） - 避免在视图定义里用
GROUP BY、DISTINCT、集合操作符（UNION） - WHERE 条件里不要过滤掉 key-preserved 表的主键列，否则可能破坏“保存性”判断
- Oracle 11g 之前可用
/*+ bypass_ujvc */hint 强行绕过检查，但风险高：一对多时会重复更新同一行，11g+ 已失效
比 UPDATE INLINE VIEW 更稳更快的替代方案有哪些？
真正在生产环境扛量的，往往不是可更新视图，而是 MERGE 和带 ROWID 的分步更新。它们不依赖视图可更新性，逻辑更可控。
推荐顺序和适用场景：
-
MERGE INTO：适合大数据量、源表（USING部分）能走索引或全表扫描的场景；支持WHEN MATCHED THEN UPDATE，天然避免 NULL 覆盖；并行 DML 可开（ALTER SESSION ENABLE PARALLEL DML） - 子查询 +
EXISTS写法：UPDATE t1 SET col = (SELECT t2.val FROM t2 WHERE t2.id = t1.t2_id) WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.id = t1.t2_id)；简单清晰，但注意子查询必须返回单行，否则报ORA-01427 - 基于
ROWID的 PL/SQL 批量更新：先用SELECT t1.rowid, t2.val BULK COLLECT拿数据，再用FORALL UPDATE；适合需要复杂逻辑或中间校验的场景，但要注意ORDER BY ROWID对缓存友好性的影响
性能差异到底卡在哪？关键看执行计划里的 “B1”
用子查询方式写 UPDATE，如果执行计划里出现 B1（即 “buffered subquery”），说明 Oracle 把子查询当成了嵌套循环驱动，对 t1 的每一行都去查一遍 t2 —— 这就是慢的根源。而 MERGE 或 INLINE VIEW（配合合适索引）大概率走 HASH JOIN 或 SORT MERGE，批量处理。
验证方法：
- 跑
EXPLAIN PLAN FOR后查DBMS_XPLAN.DISPLAY，重点看 ID=3 附近有没有B1 - 对比
MERGE的计划，通常会有VIEW或INLINE VIEW节点，且驱动方式是TABLE ACCESS FULL+HASH JOIN - 如果源表
t2关联字段没索引，无论哪种写法都会慢；先建索引比调写法更有效
真正容易被忽略的是：可更新视图的“正确性”和“性能”其实是两回事。你能让 UPDATE (SELECT ...) 跑通，不代表它快；而 MERGE 即使不满足视图可更新条件，也能高效完成任务 —— 别被 ORA-01779 绑架了优化思路。
