SQL视图执行本质是视图展开，即优化器在查询重写阶段将视图定义内联至外部查询，形成合并后的SQL再统一优化；若展开后谓词成功下推且基表有匹配索引，则可走索引查找而非全表扫描。
SQL视图本身不存储数据，它的“执行”本质是把视图定义的 SELECT 语句内联到外部查询中，再由优化器统一重写和规划——这个过程叫视图展开（view expansion）。它不是性能加速器，而是优化器能否生效的前提。
视图展开发生在查询重写阶段，不是运行时动态拼接
当执行 SELECT * FROM my_view WHERE id = 100 时，MySQL/PostgreSQL/Oracle 等主流数据库不会先算出视图全量结果再过滤。优化器在解析后、生成执行计划前，就把视图替换成其原始定义，例如：
CREATE VIEW my_view AS SELECT id, name FROM users WHERE status = 'active';
→ 展开为：
SELECT id, name FROM users WHERE status = 'active' AND id = 100;
这个替换是语法树层面的，发生在优化器的“查询重写”环节，后续所有优化（索引选择、条件下推、连接顺序）都基于这个合并后的 SQL 进行。
常见错误现象：
- 以为
CREATE VIEW v AS SELECT * FROM t+WHERE能走索引，结果执行计划里仍是全表扫描——说明展开后谓词没被下推，或基表缺对应索引 - 视图里用了
ROW_NUMBER()或嵌套子查询，外部WHERE完全无法穿透，展开后变成两层嵌套，rows暴涨
展开失败的典型写法：人为制造不可下推结构
即使在 MySQL 8.0.29+，以下写法仍会中断条件下推，导致先物化再过滤：
- 视图定义含显式派生表：
SELECT * FROM (SELECT id, name FROM users) AS t—— 多一层括号就断掉下推链 - 使用相关子查询：
SELECT u.*, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) cnt FROM users u - UNION 后带
LIMIT或ORDER BY：SELECT ... FROM t1 UNION SELECT ... FROM t2 ORDER BY id - 视图字段用函数包裹：
UPPER(name)或DATE(created_at)，外部条件无法匹配索引列
这些写法会让优化器放弃谓词下推，执行计划中 rows 值接近基表总行数，而非过滤后预期值。
如何验证展开是否成功并触发条件下推
关键不是看视图能不能查，而是看优化器有没有把外部条件“塞进”基表扫描里：
- 用
EXPLAIN FORMAT=TREE（MySQL 8.0.16+）查视图查询，找Condition pushdown: true字样 - 对比
EXPLAIN的rows：若SELECT * FROM my_view WHERE id = 123的rows≈ 1，说明下推成功；若 ≈ 基表总行数，说明失效 - 临时关闭功能验证：
SET optimizer_switch='derived_condition_pushdown=off';，再跑EXPLAIN，看rows是否明显变大 - 避免用
SELECT *测试——字段越多，展开后优化器越可能退化；明确列出所需列，减少重写复杂度
真正影响性能的从来不是“视图”这个语法糖，而是展开后那条实际执行的 SQL 能不能被优化器高效处理。写视图时少套一层 SELECT，少用一次函数，多给基表加一条联合索引，比任何视图命名规范都管用。
