视图查询变慢90%源于底层表索引缺失、join膨胀或嵌套展开导致低效执行计划；需用show create view展开视图sql并手动拼接外部条件后explain分析真实路径。
视图查询变慢，90%不是视图本身的问题，而是底层表的索引缺失、JOIN逻辑膨胀或嵌套视图展开后生成了低效执行计划。 直接改视图定义往往治标不治本，得先确认它“慢在哪儿”——是解析阶段卡住？执行时扫描太多行？还是被当作子查询反复计算？
怎么看视图实际执行了什么SQL
MySQL/PostgreSQL 中，EXPLAIN 对视图不起作用（它只显示“view”字样），必须把视图定义展开成原始语句再分析。否则你看到的 type=ALL 或 rows=1000000 是假象。
- 用
SHOW CREATE VIEW view_name拿到视图定义，复制其中的SELECT语句 - 把 WHERE 条件、ORDER BY、LIMIT 等外部过滤条件手动拼进去，形成完整查询
- 对这个拼好的语句执行
EXPLAIN，这才是真实执行路径 - 特别注意：如果视图里用了
UNION或多层嵌套子查询，展开后可能触发临时表（Using temporary）或多次全表扫描
为什么加了WHERE条件，视图还是全表扫描
视图本身不存储数据，也不自带索引。即使你在查询时写了 WHERE user_id = 123，如果视图定义里包含 JOIN 或聚合（如 GROUP BY），优化器可能无法下推该条件到底层表，导致先算完所有结果再过滤。
- 检查视图定义中是否有
SELECT *、DISTINCT、窗口函数或HAVING——这些都会阻碍条件下推 - 如果视图基于多个表 JOIN，确保
WHERE字段在驱动表上有合适索引；否则可能走被驱动表全扫 - MySQL 8.0+ 支持
ALGORITHM = MERGE视图（默认），但遇到子查询或聚合会自动降级为TEMPTABLE，此时EXPLAIN显示type=ALL是必然的
嵌套视图让性能雪上加霜
一个视图引用另一个视图，等于两层 SQL 展开。每嵌套一层，优化器决策空间越小，越容易放弃使用索引，甚至生成重复计算逻辑。
- 用
SHOW CREATE VIEW逐层展开，直到所有SELECT都落到基础表 - 重点关注中间层是否做了不必要的
GROUP BY或ORDER BY——它们在嵌套中无法被外层条件裁剪 - 如果某层视图只用于少数几个查询，考虑直接内联（inlining）到业务 SQL 中，绕过视图抽象
- PostgreSQL 的
MATERIALIZED VIEW可缓存结果，但需手动刷新，且不适用于高频更新场景
真正难的不是发现“视图慢”，而是判断“慢在哪一层”。很多团队花半天调视图定义，结果发现根子在一张没建联合索引的订单表上。别急着重构视图，先把它彻底拆开，一行一行 EXPLAIN 到底。
