怎么看 EXPLAIN
输出里的 type
和 key
关键看是否走了索引、走的什么类型索引。
type是扫描方式，从差到好大致是：
ALL（全表扫描）→
index（全索引扫描）→
range（范围查找）→
ref（非唯一索引等值匹配）→
eq_ref（主键/唯一索引等值连接）→
const（主键或唯一索引等值查询，只返回一行）。
key字段显示实际使用的索引名，如果是
NULL，说明没走索引。
常见陷阱：
type是
index不等于高效——它可能只是遍历整个索引 B+ 树叶子节点，和全表扫描 I/O 量接近 即使
key显示有索引，但
rows值极大，说明索引选择性差或条件没用上最左前缀 联合索引中，
WHERE a = ? AND b > ?能用到
(a,b)的全部，但
WHERE b > ?单独出现就完全用不上
EXPLAIN FORMAT=TREE
比传统格式多看出什么
MySQL 8.0+ 支持
FORMAT=TREE，能直观看到执行计划的嵌套结构和访问顺序，尤其对包含 JOIN、子查询、UNION 的语句更友好。它会明确标出“使用了物化”“使用了缓存结果”“是否下推条件”等信息。
实操建议：
遇到DEPENDENT SUBQUERY或
MATERIALIZED，优先检查子查询能否改写为 JOIN；物化虽快，但首次执行开销大且结果不复用 看到 符号（如
Filter: (t1.id > 100)），说明该条件在存储引擎层未下推，而是在 Server 层过滤，意味着回表后还要二次筛选 对比
FORMAT=TRADITIONAL和
FORMAT=TREE的
rows预估差异，若 TREE 版本预估明显更小，说明优化器对某些条件做了更精细估算（比如利用了统计信息）
为什么加了索引，EXPLAIN
还显示 type=ALL
不是建了索引就自动用，MySQL 优化器会根据成本估算决定是否走索引。常见原因包括：
查询条件用了函数或表达式：WHERE YEAR(create_time) = 2023→ 索引失效；应改写为
WHERE create_time >= '2023-01-01' AND create_time隐式类型转换：
user_id是
INT，但写成
WHERE user_id = '123'→ 字符串转数字可能触发全表扫描 索引列参与了运算：
WHERE score * 2 > 100→ 无法使用
score索引 数据分布倾斜：某字段只有两个值（如
status IN ('active','inactive')），优化器认为走索引反而比全表扫描更慢
验证方法：用
ANALYZE TABLE tbl_name更新统计信息，再看
EXPLAIN是否变化；或强制指定索引
SELECT ... FROM tbl_name USE INDEX (idx_name) ...对比执行时间。
EXPLAIN
里 Extra
字段哪些值必须警惕
Extra是执行细节补充，几个高频危险信号：
Using filesort：需要额外排序，说明
ORDER BY字段没被索引覆盖，或排序方向不一致（如索引是
ASC，却
ORDER BY ... DESC）
Using temporary：创建了临时表，常见于
GROUP BY+ 非索引字段、
DISTINCT+ 多列、含聚合的
UNION；联合索引要包含所有
GROUP BY列且顺序一致
Using index condition：说明用了 ICP（Index Condition Pushdown），是好事；但若同时出现
Using where，表示还有部分条件在 Server 层过滤，需检查是否遗漏索引列
Impossible WHERE：条件恒假，比如
WHERE id = 1 AND id = 2，这类语句不会真正执行，但说明 SQL 写错了
复杂点在于，有些
Extra组合看似合理实则低效，比如
Using index; Using filesort表示虽然用了覆盖索引，但排序仍要额外步骤——这时候得看排序字段是否也能纳入索引末尾形成“排序+查询”复合覆盖。
