看懂sql执行计划，核心是抓住几个关键字段——它们直接暴露查询是否走索引、扫描多少行、有没有临时表或排序、是否关联低效。不需要背全12列，盯住 type、key、rows、Extra 这四列，再结合 id 和 select_type 理清执行逻辑，基本就能定位性能瓶颈。
type：访问类型，判断是否高效走索引
这一列反映mysql如何查找数据，顺序从优到劣是：const → eq_ref → ref → range → index → ALL。重点关注是否掉到 index 或 ALL（全表扫描）。
- const：通过主键或唯一索引等值匹配，只查1行，最快
- eq_ref：多表连接时，被驱动表用主键/唯一索引等值关联，效率高
- ref：非唯一索引等值查询，可能返回多行，尚可
- range：索引范围扫描（如
WHERE age BETWEEN 20 AND 30），注意范围是否过大 - index：索引全扫描，遍历整棵B+树，比ALL略好但代价仍高
- ALL：全表扫描，无索引可用，是重点优化目标
key 和 key_len：实际用了哪个索引？用了索引的多少字节？
key 显示真正生效的索引名；key_len 表示该索引中被使用的字节数（不是字段长度，而是索引字段按字符集和类型计算的存储长度）。
- key 为 NULL，说明完全没走索引，优先检查 WHERE 条件字段是否有索引、是否符合最左前缀原则
- key 有值但 key_len 明显偏小（比如联合索引
(a,b,c)，key_len 只够 a 字段），说明只用到了部分索引，b/c 未生效 - 对比 possible_keys 和 key，如果 possible_keys 有多个而 key 只选其一，可结合业务判断是否需要强制指定索引（谨慎使用 hint）
rows：预估扫描行数，最直观的性能信号
MySQL基于统计信息估算需要读取多少行才能得到结果。这个值不是精确值，但量级差异极大时非常有参考价值。
- rows = 1 或个位数：通常没问题
- rows 达到几万甚至百万：即使 type 是 range 或 ref，也可能成为慢点，需检查条件是否可缩小范围、索引是否覆盖
- 若 rows 远大于实际返回行数（比如查10条却扫10万行），大概率存在索引失效或统计信息过期，可运行
ANALYZE table更新
Extra：藏在背后的“副作用”，常被忽略的关键提示
这一列没有固定格式，但每条信息都指向具体问题：
- using filesort：需要额外排序，未利用索引完成 ORDER BY，考虑添加覆盖排序字段的联合索引
- Using temporary：创建了临时表，常见于 GROUP BY、DISTINCT、union 或某些子查询，尽量避免
- Using index：走了覆盖索引，只查索引不回表，是理想状态
- Using where：表示存储引擎返回后还需Server层过滤，不一定坏，但如果配合 ALL 或 index 就值得警惕
- Impossible WHERE：条件恒假，SQL写错了，比如
WHERE 1=2
id 和 select_type：理清执行顺序和结构复杂度
它们不直接反映性能，但决定你能否正确解读其他字段。
- id 相同：从上到下顺序执行，属于同一层级
- id 不同：数字越大越先执行（比如子查询 id=2，外层 id=1，则先算子查询）
- select_type = DERIVED：from 中的子查询，会生成临时表，注意 rows 是否过大
- select_type = DEPENDENT SUBQUERY：相关子查询，每次外层行都要执行一次，极易变慢，优先改写为 JOIN