嵌套视图本身不导致全表扫描，真正触发TABLE ACCESS FULL的是谓词无法下推、索引未命中或统计信息失准；需重点查看执行计划中Predicate Information是否为filter而非access、视图展开后基表是否仍被全扫、Cardinality估算是否严重偏离实际。
嵌套视图本身不会导致全表扫描，真正触发 TABLE ACCESS FULL 的是优化器无法下推谓词、索引未命中或统计信息失准——而嵌套结构只是让这些问题更难被发现。
怎么看执行计划里哪一层在扫全表
别只盯着最外层的 EXPLAIN 输出。重点看三处：
- 每一行的
Predicate Information（Oracle）或Extra（MySQL）列：如果写的是filter("t1"."status" = 'ERROR')而不是access("t1"."id" = :b1)，说明这个条件没走索引查找，只是事后过滤 - 视图展开后的真实表名是否还在执行计划中出现：比如视图
v_log_detail定义为SELECT * FROM log_table，但执行计划里却显示VIEW节点包裹着log_table，且该节点下是TABLE ACCESS FULL，那问题就在视图定义或外层调用方式上 - Cardinality 估算值是否严重偏离：比如计划预估
rows=10，实际返回500000，这通常意味着内层子查询阻断了外层 WHERE 下推
为什么加了 WHERE 还是全表扫描
常见于以下几种嵌套组合：
- 视图里用了
ROWNUM或ORDER BY：Oracle 会强制物化结果，外层WHERE id = 123只能作用于物化后的结果集，无法穿透到基表 - 外层 JOIN 的 ON 条件字段，在内层视图里被表达式包裹：比如视图定义里写
UPPER(name) AS name_upper，外层却用ON v.name_upper = t2.code，即使t2.code有索引，UPPER(name)也导致基表name列无法用普通索引 - MySQL 中视图嵌套超过 2 层：优化器放弃代价估算，直接选最保守路径，表现为
type: ALL和巨量rows - SQL Server 里子查询没加
TOP或明确WHERE，触发Table Spool (Eager)物化整个中间集，后续所有操作都基于这个临时结果
怎么快速验证是不是视图嵌套惹的祸
绕过视图，直接跑它最内层的 SELECT 语句，加上和外层完全一致的 WHERE 条件：
- 复制视图 DDL，把
CREATE VIEW v AS SELECT ...里的SELECT部分拿出来，手动拼上外层条件，再EXPLAIN - 如果这时能走索引、
rows显著下降，说明问题出在视图封装带来的优化器“认知障碍”上，而不是基表本身 - 特别注意 MySQL：如果视图定义含
SELECT *，外层引用时又只取其中几列，优化器可能仍会读取所有字段，导致 I/O 暴增；应显式写出所需字段 - Oracle 用户可加
/*+ NO_MERGE */强制不合并视图，再对比执行计划变化——若加了之后反而变快，说明原先是视图合并干扰了索引选择
修复时最容易被忽略的细节
很多人改完视图就以为万事大吉，但下面这些点不检查，问题还会复发：
- 视图里涉及的基表，其统计信息是否更新？
DBMS_STATS.GATHER_TABLE_STATS或ANALYZE TABLE不是“做一次就永远有效” - MySQL 视图定义里用了
UNION ALL，但各分支字段类型不一致（如一个分支是VARCHAR(10)，另一个是VARCHAR(50)），会导致隐式转换，索引失效 - SQL Server 中，视图若引用了其他数据库的表（跨库查询），默认不启用分区裁剪，哪怕目标表是分区表，也会扫全分区
- 所有数据库里，函数索引（如
UPPER(col)）必须和查询中使用的函数完全一致，大小写、括号、空格都不能差——WHERE UPPER(name) = 'ABC'能用，但WHERE upper(name) = 'ABC'在某些版本可能就不认
