视图能否利用复合索引取决于其定义是否满足最左前缀原则、覆盖索引要求及无函数操作等条件；需通过explain验证执行计划。
视图定义中 WHERE 条件必须匹配复合索引最左前缀
视图本身不存储数据，也不直接拥有索引；它只是保存了一条 SELECT 语句。数据库在执行基于视图的查询时，会将视图逻辑“展开”后与基表的实际索引匹配。因此，能否用上基表上的复合索引，完全取决于视图里写的条件是否满足最左前缀原则。
例如基表 orders 上有复合索引 (user_id, status, created_at)，那么以下视图定义能有效利用该索引：
CREATE VIEW v_user_active_orders AS SELECT user_id, status, created_at FROM orders WHERE user_id = 1001 AND status = 'shipped';
而下面这个视图就无法使用该索引的 status 或 created_at 部分：
CREATE VIEW v_recent_orders AS SELECT * FROM orders WHERE created_at > '2025-01-01';
- 即使基表有
(user_id, status, created_at)索引，created_at不是最左列，单独查它不会走这个复合索引 - 视图里没写
user_id或user_id + status，优化器无法下推并命中索引前缀 - 若你后续对
v_recent_orders加AND user_id = 1001，部分数据库（如 MySQL 8.0+）可能做谓词下推，但不能依赖——得看执行计划
SELECT 列列表必须是复合索引的前缀子集才能触发覆盖索引
覆盖索引能避免回表，前提是查询涉及的所有字段都包含在同一个索引中。视图若想让下游查询自动享受覆盖优势，它的 SELECT 列必须严格来自复合索引的列，且不能多出基表其他字段。
比如基表 users 有索引 (city, last_name, email)，下面这个视图可支持覆盖：
CREATE VIEW v_city_contacts AS SELECT city, last_name, email FROM users WHERE city IS NOT NULL;
但如果写成：
SELECT city, last_name, email, phone FROM users ...
哪怕 phone 是基表字段，只要它不在索引里，就会强制回表——视图定义里多这一列，就破坏了覆盖能力。
- 视图返回的每列都必须落在同一复合索引内，顺序不限，但不能超出索引列集合
-
SELECT *几乎必然破坏覆盖，除非该复合索引恰好包含基表全部字段（极少见） - 如果基表主键是聚簇索引（如 InnoDB），且你只查主键列，那默认就是覆盖——但和复合索引无关
避免在视图中对索引列使用函数或表达式
一旦在视图定义里对复合索引中的列做计算、类型转换或函数包装，该列就无法参与索引查找。这是最容易被忽略的硬伤。
假设索引是 (order_date, status)，下面这些写法都会让索引失效：
WHERE YEAR(order_date) = 2025 WHERE order_date::date = '2025-03-01' WHERE status || '' = 'completed'
即使下游查询再简单，只要视图内部已“污染”了索引列，优化器就无法安全下推范围扫描。
- 不要在视图
WHERE或SELECT中对索引列调用UPPER()、TRIM()、DATE()等函数 - 隐式转换也要警惕：比如
WHERE user_id = '123'（user_id是INT），视图里这么写，索引就废了 - 如果业务真需要函数化查询，考虑用生成列（generated column）+ 新索引替代，而不是在视图里硬套
ORDER BY 和 GROUP BY 必须与复合索引顺序一致才能免排序
复合索引天然有序。如果视图里写了 ORDER BY 或 GROUP BY，且字段顺序和复合索引完全一致，数据库可直接利用索引物理顺序，跳过额外排序步骤。
比如索引是 (category, score DESC, created_at ASC)，这个视图能免排序：
CREATE VIEW v_top_items AS
SELECT category, score, created_at
FROM items
WHERE category IN ('A', 'B')
ORDER BY category, score DESC, created_at ASC;
但换成：
ORDER BY category, created_at, score DESC
就不行——中间字段错位，索引无法提供所需顺序。
-
ORDER BY字段必须是索引列的**连续前缀**，方向（ASC/DESC）也需匹配（MySQL 8.0+ 支持混合方向，但旧版本要求全一致） -
GROUP BY同理；若含聚合函数（如COUNT(*)），还需确认是否满足索引覆盖，否则仍要回表 - 视图里写
ORDER BY不保证最终结果有序——除非外部查询也显式加ORDER BY，但免排序优化只在视图展开时生效
实际部署时，最常被绕过的点是：以为“建了复合索引，视图随便写也能用上”。其实视图只是语法糖，它不改写优化器行为。真正起作用的是展开后的 SQL 是否符合索引使用前提——列顺序、无函数、前缀匹配、覆盖完整。每次改视图，都该用 EXPLAIN 看一眼执行计划里的 key 和 Extra 字段，别凭感觉。
