视图本身不决定是否全表扫描，真正触发全表扫描的是视图定义里的sql写法及外层查询引用方式；必须通过避免select*、确保where条件可下推、join字段有索引、用explain验证执行计划来优化。
视图本身不决定是否全表扫描，真正触发全表扫描的是视图定义里的 SQL 写法 + 外层查询对视图的引用方式。直接在视图上加索引不可能（MySQL 不支持视图索引），所以优化必须落在“怎么写视图”和“怎么查视图”上。
视图定义里用了 SELECT * 或未限定 WHERE 条件
这是最常见也最容易被忽略的坑：视图只是封装了 SQL，它不会自动过滤数据。如果视图定义是 CREATE VIEW v_user AS SELECT * FROM users，而你执行 SELECT name FROM v_user WHERE id = 123，MySQL 仍可能先展开整个视图（即全量读 users 表），再做外层过滤。
- 避免
SELECT *，只选真正需要的列，减少回表或临时表开销 - 视图定义中尽量带高频筛选条件（如
WHERE status = 'active'），但注意这会固化逻辑，需业务确认是否可接受 - 如果视图用于固定场景（如后台报表），可考虑用物化思路：把结果存到临时表或汇总表，而非每次都查原表
外层查询对视图字段做了函数/表达式操作
视图字段本质是表达式别名，一旦在外层 WHERE 中对它加工，优化器就无法下推到基表，索引自然失效。
- 错误写法：
SELECT * FROM v_user WHERE YEAR(create_time) = 2024→create_time是视图里从基表 SELECT 出来的，但加了函数后无法命中基表索引 - 正确做法：把函数操作挪到基表层，比如改视图定义为
SELECT ..., create_time FROM users WHERE create_time >= '2024-01-01'，外层直接WHERE create_time - 同理，
WHERE UPPER(name) = 'ABC'会失效；应确保视图输出的是原始列，且外层查时用name = 'ABC'（大小写敏感需配合 collation）
JOIN 视图时没走驱动表+索引组合
当视图参与 JOIN（如 SELECT * FROM v_order JOIN v_user ON v_order.user_id = v_user.id），优化器可能因无法预估视图结果集大小，放弃使用 v_user.id 上的索引，转而走嵌套循环或临时表。
- 优先让小结果集的视图作驱动表（例如用户视图通常比订单视图小），可用
STRAIGHT_JOIN强制顺序（但需验证执行计划） - 确保 JOIN 字段在基表上有索引：比如
v_user.id对应基表users.id必须是主键或有索引，且类型完全一致（不能一边是BIGINT一边是INT） - 避免视图里已有 JOIN，外层再 JOIN —— 这容易触发多层派生表（
<derivedn></derivedn>），EXPLAIN 中 type 常为ALL或DEPENDENT SUBQUERY
没验证视图实际执行路径，只信名字不看 EXPLAIN
视图名看着清晰，不代表执行高效。MySQL 5.7+ 会尝试将外层条件“下推”到视图定义中，但能否成功取决于写法是否满足下推规则（如无聚合、无 DISTINCT、无子查询等）。
- 每次修改视图或新写查询，必须跑
EXPLAIN FORMAT=TRADITIONAL SELECT ... FROM v_xxx ...，重点看：
–key是否非 NULL
–type是否为const/ref/range（而非ALL）
–Extra是否含Using temporary或Using filesort - 如果发现
type=ALL，说明基表被全扫了，此时要拆开视图 SQL，单独测试各部分，定位是哪一环断了下推（比如视图里用了GROUP BY就必然阻断下推） - 某些复杂视图，干脆不用视图，改用 CTE（MySQL 8.0+）或临时表，可控性更高
真正卡住性能的，往往不是“用了视图”，而是把视图当黑盒，绕过了对基表访问路径的控制。只要外层查询条件能穿透到基表索引字段，且不破坏最左前缀、不隐式转换、不函数包裹，视图和普通表没区别。
