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 优化器会根据成本估算决定是否走索引。常见原因包括：
