先看EXPLAIN中右表type是否为ALL或index，若是则未走有效索引；常见原因包括ON字段类型不一致、右表缺少合适索引、视图中对字段使用函数、JOIN顺序不合理及统计信息过期未更新。
LEFT JOIN 视图里右表字段没走索引，怎么查
直接看 EXPLAIN FORMAT=TREE（MySQL 8.0+）或 EXPLAIN (ANALYZE, BUFFERS)（PostgreSQL），重点盯右表的 type 字段：如果出现 ALL 或 index（非 ref/eq_ref），基本就是没走有效索引。
常见原因有三个：
-
ON字段类型不一致，比如左表user.id是BIGINT，右表order.user_id是VARCHAR，触发隐式转换，索引失效 - 右表
ON字段没单独建索引，或复合索引没按最左前缀匹配——例如ON b.a_id = a.id AND b.status = 'active'，但只建了(status)索引，没建(a_id, status) - 视图定义里对右表字段用了函数，比如
ON DATE(b.created_at) = DATE(a.date)，B+树索引无法跳过函数直接比对
视图中多个 LEFT JOIN，哪个表该放最前面
别按业务主次排，按「实际驱动顺序」排：把 WHERE 条件过滤后行数最少、选择性最高的表放在 FROM 后第一个位置，也就是整个 JOIN 链的最左侧。
例如一个日志分析视图：FROM log LEFT JOIN user ON log.uid = user.id LEFT JOIN dept ON user.dept_id = dept.id，如果加了 WHERE log.created_at > '2026-05-01'，但 log 表没索引或数据量极大，而 dept 只有几十行，那就该改成：FROM dept LEFT JOIN user ON dept.id = user.dept_id LEFT JOIN log ON user.id = log.uid AND log.created_at > '2026-05-01'——把小表前置，再把时间条件挪进 ON，避免右表全扫。
关键判断依据是 EXPLAIN 输出里 rows 最小、type 是 const 或 range 的那张表，它大概率才是真实驱动表。
视图字段太多，怎么确认是否用了覆盖索引
执行 EXPLAIN 后看 Extra 列：出现 Using index 才算真正命中覆盖索引；如果写的是 SELECT * 或包含未被索引覆盖的字段（比如 TEXT 类型），就一定会回表，Extra 会显示 Using where; Using index condition 或干脆没 Using index。
要让视图走覆盖索引，得满足两个硬条件：
- 所有
SELECT字段 + 所有WHERE/ON过滤字段，都必须落在同一个联合索引里 - 联合索引列顺序要匹配查询模式：等值条件字段（如
status = 'done'）放最左，范围字段（如created_at > ?）放中间，最后才是用于 JOIN 或 SELECT 的字段（如user_id,name）
比如视图查 user.name, order.amount, order.status，且常带 WHERE order.status = 'paid' 和 AND order.created_at > ?，那 order 表上最优索引是 (status, created_at, user_id, amount)，而不是 (user_id, status, amount)。
为什么改了索引，视图性能还是没变
视图本身不存执行计划，每次调用都重新解析生成执行计划。所以即使你给右表加了新索引，优化器也可能因为统计信息过期、数据倾斜严重、或成本估算认为全表扫描更便宜，而继续忽略它。
必须做三件事才能让改动生效：
- 执行
ANALYZE TABLE order（MySQL）或VACUUM ANALYZE order（PostgreSQL）更新统计信息 - 检查
EXPLAIN输出里是否真的用了新索引——别只看有没有建，要看执行时有没有走 - 如果优化器固执地不用，MySQL 可对右表加
FORCE INDEX (idx_name)，PostgreSQL 需配合pg_hint_plan插件用/*+ IndexScan(b idx_name) */
最隐蔽的坑是：视图嵌套多层，外层查询加了 WHERE，但条件落在最内层右表字段上，而那个表在视图定义里根本没被过滤——这时索引再好也白搭，得把条件下推到视图定义的 ON 子句里，或者重写为带子查询的视图。
