视图无独立执行计划，EXPLAIN 查询视图时实际显示的是内联展开后基表的执行计划；需关注条件下推、索引使用及聚合是否导致全量计算。
直接对视图查询加 EXPLAIN 就行，别试图“查视图本身的执行计划”
视图不是实体对象，没有独立的执行计划。数据库在执行 SELECT * FROM my_view 时，会先将视图定义内联展开（view inlining），再生成最终执行计划。所以你看到的永远是「查询视图这条语句」的执行计划，而不是“视图自己”的计划。
常见错误是试图对 CREATE VIEW 语句或视图 DDL 执行 EXPLAIN，这会报错或返回空/无意义结果。正确做法就是把视图当普通表用，在它上面写查询，再加 EXPLAIN。
- MySQL：直接
EXPLAIN SELECT * FROM customer_order_summary WHERE total_orders > 5; - PostgreSQL：同上，
EXPLAIN ANALYZE更推荐，能拿到实际耗时与行数 - SQL Server：在 SSMS 中选中查询 → 按
Ctrl+M看预估计划，或Ctrl+L看实际计划
重点关注展开后 WHERE 条件是否下推、索引是否还能用
视图内联后，优化器会尝试把外层查询的过滤条件（如 WHERE dept = 'IT'）下推到基表扫描阶段。但下推是否成功，取决于视图定义和数据库版本。
典型陷阱：
- 视图里用了
GROUP BY+ 聚合函数（如COUNT()），外层WHERE无法下推，导致先算全量聚合再过滤，rows值巨大 - 视图定义含
ORDER BY但没配LIMIT，外层再加ORDER BY可能触发二次排序（Using filesort） - 视图基于多表
JOIN，但外层只过滤其中一张表字段，若连接键没索引，仍可能走嵌套循环+全表扫描
验证方法：对比视图查询的 EXPLAIN 和等价展开 SQL 的 EXPLAIN，看 key、rows、Extra 是否一致。不一致说明下推失败或重写路径不同。
PostgreSQL / SQL Server 中可查视图依赖的物理表访问路径
某些场景下，你想确认视图到底访问了哪些基表、走了什么索引——尤其是当视图嵌套多层（视图引用视图）时。
PostgreSQL 可用：
-
EXPLAIN (VERBOSE) SELECT * FROM my_nested_view;——VERBOSE模式会显示扫描的 Relation 名称和实际使用的字段 - 结合
\d+ my_view查视图定义，手动比对字段来源
SQL Server 可用：
-
SELECT * FROM sys.dm_exec_describe_first_result_set('SELECT * FROM my_view', NULL, 0);—— 看列来源表 - 图形化执行计划中，鼠标悬停在“Clustered Index Scan”或“Index Seek”节点上，看
Object属性值是不是你预期的基表名
避免用视图掩盖低效逻辑，特别是聚合+过滤组合
一个常见反模式是：创建带 GROUP BY 的统计视图，然后在外层反复加不同 WHERE 过滤。这类视图几乎无法利用索引加速，每次查询都得重算聚合。
更优解：
- 把聚合逻辑下沉到物化视图（PostgreSQL 9.3+、SQL Server 2005+ 的 indexed view）或定期刷新的汇总表
- 改用参数化内联表值函数（TVF），让优化器有机会按参数选择索引
- 确认业务是否真需要“随时查最新聚合”，还是可接受分钟级延迟——后者更适合走异步预计算
最易被忽略的一点：视图性能问题往往不是视图本身的问题，而是底层表缺少合适索引，或者统计信息过期导致优化器选错路径。查完执行计划后，先跑一遍 ANALYZE table_name（PostgreSQL）或 UPDATE STATISTICS（SQL Server），再重看计划。
