SQL视图在业务中用得很多，但视图查询变慢时，排查起来比普通SQL更麻烦，因为视图可能嵌套视图，优化器展开后逻辑和原始写法差别很大。要解决问题，核心是从执行计划看真实执行路径，并处理嵌套视图带来的额外开销。
一、通过执行计划排查视图性能
视图本身不存储数据，数据库在执行时会将视图定义展开到主查询中。直接看视图SQL往往看不出问题，必须分析实际执行计划。
1. 查看执行计划
以MySQL为例，在查询前加 EXPLAIN 即可：
EXPLAIN SELECT * FROM v_user_order_stat WHERE create_date >= '2023-01-01';
在结果中重点看以下列：
- type：访问类型，如果是ALL表示全表扫描
- rows：预估扫描行数，数值过大要警惕
- key：实际使用的索引，为NULL说明没走索引
- Extra：如出现Using temporary、Using filesort代表有性能隐患
2. 展开视图定义对照
先用 SHOW CREATE VIEW 拿到视图真实定义，再手写展开后的SQL对比执行计划，确认视图是否导致优化器选错连接顺序。
SHOW CREATE VIEW v_user_order_stat;
二、嵌套视图引发的性能问题
嵌套视图指一个视图引用另一个视图。这类结构常造成两个典型问题。
1. 谓词无法下推
外层查询的过滤条件不能穿透到最内层表，导致先算出大结果集再过滤。
2. 重复计算
被嵌套的视图如果在多处被引用，聚合逻辑会被重复执行。
| 问题 | 表现 | 影响 |
|---|---|---|
| 谓词不下推 | 内层全表扫描 | IO和内存浪费 |
| 重复计算 | 相同子查询多次执行 | CPU开销翻倍 |
三、嵌套视图优化方法
1. 拆平嵌套视图
将多层视图合并成单层查询，让优化器看到完整表关系。
-- 原嵌套视图 v_user_order_stat 引用 v_user_base -- 优化后直接展开 SELECT u.id, u.name, COUNT(o.id) AS order_cnt FROM user_table u LEFT JOIN order_table o ON u.id = o.user_id WHERE u.status = 1 GROUP BY u.id, u.name;
2. 使用CTE代替视图嵌套
在支持的数据库里，用WITH子句明确计算顺序，避免视图隐式展开。
WITH user_base AS ( SELECT id, name FROM user_table WHERE status = 1 ) SELECT ub.name, COUNT(o.id) FROM user_base ub LEFT JOIN order_table o ON ub.id = o.user_id GROUP BY ub.name;
3. 减少视图层级
业务允许时，把三层以上视图降到一层，并在底层表建好联合索引。
CREATE INDEX idx_user_status_id ON user_table(status, id);
4. 物化关键中间结果
对极度复杂且更新不频繁的统计视图，可建物化表定时刷新，绕开实时展开开销。
排查SQL视图性能低下，先借执行计划看清展开后的访问路径，再针对嵌套视图做拆平、下推和减层处理，多数慢查询都能明显好转。