EXPLAIN分析四要素：type判断索引使用效率（const/eq_ref最佳，ALL最差）；key与possible_keys对比看索引是否生效；rows预估扫描行数，越小越好；Extra揭示关键行为（Using index为优，Using filesort/Using temporary需优化）。
直接看 EXPLAIN 输出，重点盯住 type、key、rows、Extra 这四项，就能快速定位性能问题。面试时考官不指望你背全12列，但必须能从一行结果里读出“哪里慢、为什么慢、怎么改”。
一看 type：判断是否走索引、走得多不多
这是最优先看的指标，反映 MySQL 查数据的路径效率：
- const / eq_ref：极好，主键或唯一索引精准匹配，基本秒出
-
ref：良好，普通索引等值查询（如
WHERE status = 'active'） -
range：尚可，范围查询（
>、BETWEEN、IN），注意右边界是否截断索引 - index：危险，全索引扫描——比全表略好，但仍是遍历整棵B+树
- ALL：红色警报！全表扫描，必须加索引或重写条件
面试常考陷阱：WHERE YEAR(create_time) = 2023 → type = ALL，因为函数导致索引失效；应改为 create_time BETWEEN '2023-01-01' AND '2023-12-31'。
二看 key 和 possible_keys：索引有没有被用上
对比这两列，立刻看出优化空间：
-
possible_keys有值，但key是 NULL → 索引存在，但没被选中（常见于类型不匹配、隐式转换、OR 条件、前导通配符 like '%abc'） -
key显示具体索引名（如idx_user_age）→ 走了索引，继续看type和rows -
key是 PRIMARY 或 覆盖索引名 +Extra: Using index→ 最优路径，无需回表
举例：EXPLAIN SELECT name FROM user WHERE age = 25; 若 key = idx_age 且 Extra = Using index，说明 name 在该索引中已包含（联合索引 (age, name)），性能很好。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
三看 rows：估算扫描量，不是精确值但极具参考性
这个数字是优化器预估的“需要检查多少行”，越小越好：
- rows ≈ 1 或个位数 → 高效，通常对应 const/eq_ref/ref
- rows 接近表总行数（如 100w 行的表显示 rows=982341）→ 实际接近全扫，即使 type 不是 ALL 也要警惕
- rows 值突然变大（比如加了个 JOIN 后从 100 跳到 50000）→ 检查驱动表顺序、JOIN 字段是否有索引
注意：rows 是估算值，受统计信息影响。若明显偏离实际，可用 ANALYZE TABLE table_name; 更新统计信息。
四看 Extra：关键行为提示，藏着优化突破口
这里没有废话，全是动作信号：
- Using index ✅：覆盖索引，只查索引不回表，快
- Using where ⚠️：WHERE 条件在存储引擎层后过滤，可能有回表或扫描过多
- Using temporary ❌：创建临时表，常见于 GROUP BY、DISTINCT、复杂 ORDER BY，需优化字段或加索引
- Using filesort ❌：额外排序，ORDER BY 未命中索引顺序，应让排序字段进联合索引
- Using join buffer ⚠️：没走索引的 JOIN，靠内存缓冲硬连，小表驱动大表也救不了，必须加索引
面试高频组合：type=ref, key=idx_status, Extra=Using where; Using filesort → 说明 status 走了索引，但 ORDER BY create_time 没索引，应建联合索引 (status, create_time)。
