普通视图不提升查询效率，仅封装sql；真正提速需基表有匹配索引、统计信息准确、或改用物化视图预存结果。
Oracle视图本身不直接提高查询效率，反而可能因嵌套过深或定义不当拖慢性能；真正起作用的是配合统计信息、索引和执行计划优化后的使用方式。
视图只是SQL语句的封装，不预计算也不缓存结果
创建视图 CREATE VIEW v_emp_dept AS SELECT e.name, d.dept_name FROM emp e JOIN dept d ON e.dept_id = d.id 并不会物化数据，每次查询 SELECT * FROM v_emp_dept WHERE name LIKE 'A%' 都会重写为底层SQL并重新解析执行。这意味着：
- 视图不减少逻辑读，也不跳过全表扫描
- 如果底层表缺少
name列上的索引，WHERE 条件仍会触发全表扫描 - 多层嵌套视图（如 v1 → v2 → v3）会让优化器更难生成高效执行计划，尤其在 Oracle 11g 及以前版本中易触发次优连接顺序
真正提升效率的三个关键点
视图要“快”，必须满足以下条件之一或组合：
-
基表有匹配的索引：比如视图过滤字段
status上存在复合索引(status, created_date)，且查询中用了该字段做等值判断 -
统计信息准确：运行
DBMS_STATS.GATHER_TABLE_STATS更新基表统计后，CBO 才能正确估算行数，避免误选嵌套循环而非哈希连接 -
使用物化视图（MV）替代普通视图：仅当业务允许一定延迟（如 T+1），且查询涉及大量聚合/连接时，
CREATE MATERIALIZED VIEW mv_sales_summary...才能真正提速——它会把结果存物理表中，并支持快速刷新
PL/SQL Developer里查视图性能的实操动作
在 PL/SQL Developer 的 SQL 窗口中分析视图性能，别只看 SELECT * FROM my_view 是否跑得动：
- 选中整条语句，按
F5查看执行计划，重点看Operation列是否出现VIEW节点下的TABLE ACCESS FULL - 右键点击执行计划中的表名 → “Describe Table”，确认对应列是否有索引；没有就补
CREATE INDEX idx_emp_status ON emp(status) - 若视图含
GROUP BY或窗口函数，且频繁调用，考虑改用物化视图，并在刷新策略中启用ON COMMIT或FAST刷新 - 避免在视图定义里写
SELECT *，尤其当基表后续加了大字段（如BLOB），会导致调用方无谓传输大量数据
最容易被忽略的是：视图的“可维护性优势”常被误当成“性能优势”。一个封装了复杂权限逻辑的视图，对开发友好，但执行效率完全取决于它背后那条被重写的 SQL —— 该查什么索引、走什么连接、是否能利用分区裁剪，一点没少算。
