视图无实际数据，执行时会被内联展开为底层表JOIN与过滤的真实查询路径；SQL Server用SET STATISTICS XML ON查看执行计划中的TableScan/IndexSeek，PostgreSQL用EXPLAIN (ANALYZE, BUFFERS)关注Rows Removed by Filter和Buffers，MySQL 8.0+用EXPLAIN FORMAT=TREE识别Using temporary/filesort。
怎么看视图实际执行了哪些表和索引
视图本身不存数据，SQL Server 或 PostgreSQL 执行时会把视图定义“内联展开”进主查询，最终跑的是展开后的语句。所以直接看 SELECT * FROM my_view 的执行计划，看到的其实是底层多表 JOIN + 过滤的真实路径，不是视图“自己”的计划。
实操建议：
- 在 SQL Server 中，用
SET STATISTICS XML ON后执行视图查询，打开执行计划 XML，重点找<relop></relop>节点里的TableScan、IndexSeek、Nested Loops—— 这些才是真实代价来源 - PostgreSQL 用
EXPLAIN (ANALYZE, BUFFERS)，注意看Actual Rows和Buffers字段，尤其当某张表的Rows Removed by Filter占比极高，说明 WHERE 没走索引或条件写法抑制了索引下推 - MySQL 8.0+ 可用
EXPLAIN FORMAT=TREE，观察是否出现Using temporary或Using filesort，这两项常出现在视图含GROUP BY或ORDER BY但没被外层查询利用时
为什么加了 WHERE 条件视图还是全表扫描
常见现象：视图定义里有 JOIN 多张大表，外层加了 WHERE t1.id = 123，但执行计划里 t2 和 t3 仍被全表扫描——这是因为优化器判断“先 JOIN 再过滤”比“先过滤再 JOIN”代价更低，或者视图定义中用了无法下推的表达式。
实操建议：
- 检查视图 SQL 中是否含
GETDATE()、NEWID()、子查询、OR条件、函数包裹列（如UPPER(name)），这些都会阻止谓词下推 - 在 SQL Server 中，尝试用
WITH (NOEXPAND)提示（仅限索引视图），强制走视图预计算结果；普通视图加该提示无效，还会报错 - PostgreSQL 中可考虑用
MATERIALIZED VIEW替代，但需手动刷新，且不支持实时更新
视图嵌套三层后性能断崖下跌怎么办
嵌套视图（A → B → C）会让优化器难以估算中间结果集大小，尤其当某层用了 TOP、OFFSET/FETCH 或聚合，容易导致基数估算严重偏差，选错连接算法或驱动表顺序。
实操建议：
- 用
sys.dm_exec_query_stats（SQL Server）或pg_stat_statements（PostgreSQL）查该视图对应的实际执行次数和平均逻辑读，确认是不是某次调用触发了最差路径 - 把嵌套拆开：用临时表或 CTE 显式物化中间结果，比如
WITH step1 AS (SELECT ...) SELECT ... FROM step1 JOIN ...，让优化器有明确的行数锚点 - 避免在视图里写
SELECT *，外层只取需要字段；否则即使只查 1 列，也可能因视图定义包含TEXT或JSON大字段，拖慢 I/O 和内存排序
MySQL 视图用到 UNION ALL 就变慢的典型原因
MySQL 对含 UNION 的视图，会默认创建内部临时表并强制使用磁盘（Using temporary on disk），哪怕每个分支都很快。更麻烦的是，外层 WHERE 通常无法下推到各分支，导致每个子查询都全量执行再合并。
实操建议：
- 改用
UNION ALL并确保各分支结果集无重叠（避免去重开销），同时给每个分支的WHERE加上相同过滤条件，比如都写WHERE status = 'active' - 如果分支来自不同库/表结构相似，考虑用分区表替代 UNION，MySQL 8.0+ 分区裁剪能有效跳过无关分区
- 实在绕不开，把 UNION 视图内容复制出来，改写成存储过程 +
INSERT INTO temp_table SELECT ... UNION ALL SELECT ...，再对外提供查询接口
真正卡住的地方往往不是视图语法本身，而是底层表缺失关键索引、统计信息陈旧、或者外层应用反复调用却没缓存结果——这些比改写视图更能立竿见影。
