EXPLAIN中type表示扫描方式，从ALL到const递进优化；key显示实际索引名，NULL代表未走索引；需结合rows、Extra及统计信息综合判断索引有效性与执行效率。
怎么看 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 表示虽然用了覆盖索引，但排序仍要额外步骤——这时候得看排序字段是否也能纳入索引末尾形成“排序+查询”复合覆盖。
