explain显示的是视图合并后的最终执行计划，无法反映原始sql的索引使用情况；定位瓶颈需单独explain视图定义中的原始select语句，并检查关联字段索引、谓词下推是否生效及algorithm是否降级为temptable。
EXPLAIN 不等于视图执行计划
直接对 SELECT * FROM v_user_orders 执行 EXPLAIN，看到的是“合并后”的最终执行树，它已经把视图定义里的所有 JOIN、WHERE、GROUP BY 全部展开重写。你根本看不出原始 SQL 中哪张表没走索引、哪个 ON 条件缺失索引、或者是否发生了全表扫描。
真正要定位性能瓶颈，必须把视图定义里的原始 SELECT 语句单独拿出来 EXPLAIN。比如视图是这样建的：
CREATE VIEW v_user_orders AS SELECT u.name, o.order_no, COUNT(oi.id) FROM users u JOIN orders o ON u.id = o.user_id JOIN order_items oi ON o.id = oi.order_id GROUP BY u.id, o.id;
那就得分别对这三张表的关联字段检查索引：确认 orders.user_id、order_items.order_id 都有单列或联合索引；否则 EXPLAIN 里会出现 type: ALL 或 rows 异常放大。
谓词下推失效是慢查询头号原因
视图里没写 WHERE user_id = ?，不代表调用时加了就能自动下推。MySQL 优化器在某些组合下会放弃下推——尤其是视图含聚合、子查询、函数或 ORDER BY（哪怕带 LIMIT）时，就会退化为先算全量再过滤。
- 典型现象：
SELECT * FROM v_user_orders WHERE user_id = 123比直接跑视图原始 SQL 慢几倍 - 验证方法：对比两者的
EXPLAIN FORMAT=TREE输出，看过滤条件是否出现在最内层扫描节点上 - 补救措施：把高频过滤字段（如
user_id、created_at）显式写进视图定义的WHERE，但要小心牺牲复用性
ALGORITHM=MERGE 和 TEMPTABLE 的性能分水岭
ALGORITHM=MERGE 是唯一能保留基表索引能力的选项；一旦降级为 ALGORITHM=TEMPTABLE，就等于强制物化中间结果到临时表，后续所有过滤、排序都只能在内存/磁盘上做，完全丢失索引加速。
哪些写法会触发自动降级？
- 视图定义中含
GROUP BY、DISTINCT、窗口函数、聚合函数（如COUNT()） - 用了不可下推的函数：比如
DATE(created_at)、UPPER(name)（除非数据库支持函数索引且已建） - 写了
ORDER BY但没配LIMIT，或LIMIT值被解析为动态表达式 - MySQL 8.0+ 对
MERGE下推更激进，但遇到子查询或用户变量仍会立即 fallback
嵌套三层以上视图基本等于自废武功
每多一层视图封装，优化器决策空间就压缩一分。MySQL 在嵌套超过三层时可能直接拒绝谓词下推，PostgreSQL 对统计信息收集也会失真，Oracle 甚至可能生成完全错误的驱动表顺序。
如果业务逻辑确实需要多层抽象（比如「用户→订单→商品→库存状态」），优先考虑以下替代路径：
- 用
WITHCTE 替代中间层视图：CTE 可被多数引擎内联，不增加解析负担 - 把最内层聚合结果物化为临时表（
CREATE TEMPORARY TABLE tmp_orders AS ...），再供上层 JOIN - 对高频固定维度（如按天汇总的订单数），改用定时任务写入物理汇总表，而非实时计算
视图不是语法糖，它是把执行逻辑的控制权部分交给了优化器——而优化器从不保证每次都做对。真正影响性能的，永远是那几个 ON 字段有没有索引，而不是你用了几个 CREATE VIEW。
