MySQL视图不走索引，性能取决于底层表索引；应避免函数操作、深嵌套，优先用CTE或物化缓存表，并以EXPLAIN验证优化效果。
MySQL视图本身不走索引，但底层表可以
视图只是封装好的 SELECT 语句，执行时会被“展开”成原始 SQL 再跑。它自己不能建索引，也不缓存结果——每次查都是实时重算。所以提升性能的关键不在视图定义本身，而在它所依赖的那些基础表是否被合理索引。
常见错误现象：EXPLAIN 显示视图查询走了 type: ALL（全表扫描），哪怕视图里只 SELECT * FROM view WHERE id = 123。
- 确保
WHERE条件中用到的字段，在底层表上有单列或复合索引 - 如果视图含
JOIN，关联字段（如orders.user_id和users.id）两端都得有索引 - 避免在视图定义里对字段做函数操作（如
UPPER(name)），否则底层索引失效 - 复合索引要注意顺序：比如视图常查
WHERE status = 'paid' AND created_at > '2025-01-01'，那就该建(status, created_at)，而不是反过来
别嵌套太深，尤其别在视图里套视图
MySQL 对视图的解析是递归展开的。一个视图引用另一个视图，再套一层，最终生成的执行计划可能完全偏离预期，优化器也容易放弃使用索引。
典型问题：CREATE VIEW v_orders_summary AS SELECT * FROM v_orders_detail WHERE ...，而 v_orders_detail 又基于 3 张表 JOIN —— 这种结构让 EXPLAIN 难以看清真实访问路径，且极易触发临时表 + 文件排序。
- 视图嵌套建议控制在 1 层以内；超过 2 层就该考虑重构成单个视图或直接用原生查询
- 如果必须复用逻辑，优先用公共表表达式（CTE，MySQL 8.0+）替代嵌套视图，CTE 至少不会被多次展开
- 用
EXPLAIN FORMAT=TREE（MySQL 8.0.16+）看实际执行树，确认有没有意外的物化步骤
用物化思路绕过 MySQL 的视图限制
MySQL 没有原生物化视图，但很多高频、低更新频次的统计类视图（比如“每个城市昨日订单数”）完全适合手动模拟：用定时任务刷一张物理表，再让视图查这张表。
例如：你有一个慢视图 v_city_daily_stats，每天只变一次，但每次查都要 JOIN 4 张大表。这时：
- 新建表
t_city_daily_stats_cache，结构和视图输出一致 - 写个脚本（
mysqldump或INSERT ... SELECT）每天凌晨跑一次，把结果灌进去 - 把原视图改成
CREATE VIEW v_city_daily_stats AS SELECT * FROM t_city_daily_stats_cache - 给缓存表加好索引，查询立刻从秒级降到毫秒级
注意点：缓存表需加 ON UPDATE CURRENT_TIMESTAMP 字段记录刷新时间，方便监控是否过期；不要用 TEMPORARY TABLE，它对其他会话不可见。
EXPLAIN 是唯一能验证优化效果的工具
所有“应该快了”的判断，不经过 EXPLAIN 都是空谈。特别是视图，你看到的 SELECT 语句和实际执行的 SQL 差很远。
- 对视图执行
EXPLAIN SELECT * FROM v_myview WHERE x = 1，重点看key列是否非 NULL、rows是否显著下降 - 如果出现
Using temporary或Using filesort，说明视图里用了GROUP BY/ORDER BY但没覆盖索引，得回到底层表补索引或改写逻辑 - MySQL 5.7 用
EXPLAIN EXTENDED+SHOW WARNINGS看展开后的 SQL；8.0 直接用EXPLAIN FORMAT=TREE更直观
最易被忽略的是：视图里写的 ORDER BY 在被外层再查时会被丢弃，除非外层也写 ORDER BY —— 这意味着你为视图加的排序逻辑，很可能白做了。
