Oracle子查询UPDATE性能差因逐行执行子查询致嵌套循环，源表反复扫描；可更新视图需满足唯一基表、等值关联、关联字段有唯一索引等条件才能避免此问题。
为什么子查询UPDATE在Oracle里容易变慢
因为Oracle对每个被更新行，都要单独执行一次子查询——相当于嵌套循环（Nested Loop），源表被反复扫描。如果源表没走索引、或匹配行多，性能会断崖式下跌。更糟的是，一旦子查询返回多行，直接报错 ORA-01427: single-row subquery returns more than one row。
用可更新视图替代子查询UPDATE的关键条件
核心是让Oracle把关联逻辑“一次性拉平”，避免逐行查源表。但不是所有视图都能更新，必须满足：
- 视图中每个目标列（要更新的字段）必须来自**唯一基表**，且该表的主键或唯一键必须出现在
WHERE关联条件中 - 连接方式只能是
=等值关联，不能是>、LIKE或函数表达式 - 源表（如
table_b）的关联字段上**必须有唯一索引或主键约束**，否则 Oracle 拒绝更新 - Oracle 11g 及以后版本，
BYPASS_UJVC提示已失效；9i/10g 虽可用，但风险高（一对多时会重复更新）
写法对比：子查询 vs 可更新视图
假设要把 table_b.name 更新到 table_a.name，基于 id 关联：
❌ 子查询写法（低效+易错）：
UPDATE table_a a SET name = (SELECT b.name FROM table_b b WHERE b.id = a.id) WHERE EXISTS (SELECT 1 FROM table_b b WHERE b.id = a.id);
✅ 可更新视图写法（推荐）：
UPDATE ( SELECT a.name AS a_name, b.name AS b_name FROM table_a a, table_b b WHERE a.id = b.id ) SET a_name = b_name;
注意：table_b.id 必须是主键或有唯一索引，否则报错 ORA-01779: cannot modify a column which maps to a non key-preserved table。
容易被忽略的执行细节
可更新视图看似简洁，但实际执行计划未必最优——它依赖优化器是否能识别出“键保留”关系。如果关联字段上没索引，Oracle 可能退化为全表扫描+哈希连接，反而比加了索引的子查询还慢。务必检查执行计划里的 KEY-PRESERVED 标记，并确认 table_b 的 id 列确实走了索引扫描（INDEX UNIQUE SCAN 或 INDEX RANGE SCAN）。没有索引保障的“可更新视图”，只是换了一种方式踩坑。
