视图查询会全表扫描是因为视图不存储数据且无索引，执行时展开为原始sql，若基表无索引、where未命中索引、或视图定义含函数/表达式，均导致type:all；需用explain查展开后执行计划，关注key、rows、extra，并确保where条件直接作用于基表可索引列。
视图查询为什么还会全表扫描
MySQL 视图本身不存储数据，只是保存了 SELECT 语句的定义。执行 SELECT * FROM view_name 时，MySQL 会把视图展开成原始 SQL，再走优化器流程——也就是说，**视图不会自动带索引，也不会绕过底层表的扫描逻辑**。如果原表没索引、WHERE 条件没命中索引、或视图定义里用了函数/表达式，照样触发 type: ALL。
EXPLAIN 查看视图实际执行计划
别只看视图名，得查它“展开后”怎么跑：
EXPLAIN SELECT * FROM my_user_view WHERE status = 'active';
重点看三处：
-
key列是否为空：为空说明没走索引 -
rows是否接近整表行数：越接近，越可能是全表扫描 -
Extra是否出现Using where; Using temporary; Using filesort：这些不是全表扫描的直接标志，但常伴随低效执行路径
注意：EXPLAIN 显示的是视图展开后的语句，可能包含多表 JOIN，要逐层确认每张基表是否都走了索引。
WHERE 条件必须落在基表可索引列上
视图里字段名是别名，但索引只存在于基表。下面这些写法极易失效：
- 视图定义中用了
YEAR(create_time)，你在查询时写WHERE create_year = 2024→ 基表create_time列无法走索引 - 视图 SELECT 了
CONCAT(first_name, ' ', last_name) AS full_name，你写WHERE full_name LIKE 'John%'→ 底层无索引支撑 - 视图基于
LEFT JOIN，你只在右表字段加 WHERE（如WHERE orders.status = 'paid'），可能让优化器放弃使用左表索引
正确做法：WHERE 条件尽量直接引用基表原始列，且确保该列有索引。例如视图基于 users.id 和 orders.user_id，就优先用 WHERE users.id = 123 或 WHERE orders.user_id = 123。
联合索引与最左前缀在视图中照常生效
视图不改变索引规则。比如基表 orders 有联合索引 INDEX idx_user_status_time (user_id, status, created_at)：
-
WHERE user_id = 100 AND status = 'shipped'→ 可命中索引 -
WHERE status = 'shipped'→ 不满足最左前缀，跳过索引 -
WHERE user_id = 100 ORDER BY created_at DESC→ 若 MySQL 版本 ≥ 8.0，可利用索引排序；5.7 则大概率触发Using filesort
视图定义里如果包含 ORDER BY 或 GROUP BY，更要小心：它们可能迫使优化器放弃范围扫描，转而先取全部结果再排序。能去掉就去掉，靠外层查询控制顺序更可控。
真正容易被忽略的是：视图定义本身可能引入隐式转换或计算，比如把 VARCHAR 字段转成大写再暴露为视图列，外部查询再拿这个列做等值判断，底层索引就废了。检查视图定义比检查调用语句还重要。
