SQL执行计划分析的时候，要关注哪些信息？
核心概念
执行计划（EXPLAIN）是MySQL提供的SQL分析工具，用于展示查询语句的执行路径和成本估算。通过分析执行计划，可以识别性能瓶颈并指导优化方向。
关键字段解析
1. type（访问类型）
表示MySQL访问表的方式，性能从优到劣排序：
| 类型 | 说明 | 性能 |
|---|---|---|
| system/const | 单表单行，通常是主键或唯一索引查询 | 最优 |
| eq_ref | 唯一索引扫描，多表关联中的最佳连接方式 | 优秀 |
| ref | 非唯一索引扫描，返回匹配某值的所有行 | 良好 |
| range | 索引范围扫描（BETWEEN、>、< 等） | 可接受 |
| index | 全索引扫描，遍历整个索引树 | 较差 |
| ALL | 全表扫描 | 最差 |
优化目标：尽量避免 ALL 和 index，争取达到 ref 或更好。
2. key（实际使用的索引）
- 显示MySQL实际选择的索引名称
- 如果为
NULL，说明未使用索引（需优化） - 对比
possible_keys（可能的索引）判断索引选择是否合理
3. rows（扫描行数估算）
- MySQL估计需要扫描的行数（不是精确值）
- 数值越小越好，几百万行扫描通常意味着性能问题
- 注意：实际扫描行数可能与估算值相差较大
4. Extra（额外信息）
关键提示信息，需重点关注：
| Extra值 | 说明 | 是否需优化 |
|---|---|---|
| Using index | 覆盖索引，无需回表 | ✅ 最优 |
| Using where | 使用WHERE过滤，常见情况 | ⚠️ 正常 |
| Using index condition | 索引条件下推（ICP） | ✅ 良好 |
| Using filesort | 需要额外排序，未使用索引排序 | ❌ 需优化 |
| Using temporary | 使用临时表（如GROUP BY） | ❌ 需优化 |
| Using join buffer | 关联查询未使用索引，需缓冲区 | ❌ 需优化 |
5. 其他关键字段
- id：查询序列号，值越大越先执行，相同id按从上到下顺序执行
- select_type：查询类型（SIMPLE、SUBQUERY、DERIVED等）
- table：当前操作的表名
- filtered：按条件过滤后剩余行的百分比（值越高越好）
实战分析示例
EXPLAIN SELECT * FROM orders
WHERE user_id = 1001
ORDER BY create_time DESC
LIMIT 10;
优化前可能的结果：
type: ALL
key: NULL
rows: 500000
Extra: Using where; Using filesort
问题识别：
type=ALL→ 全表扫描key=NULL→ 未使用索引Using filesort→ 排序未走索引
优化方案：
-- 创建联合索引
CREATE INDEX idx_user_time ON orders(user_id, create_time);
优化后结果：
type: ref
key: idx_user_time
rows: 120
Extra: Using index condition
面试答题要点
- type字段是最直观的性能指标，尽量达到ref级别以上
- key为NULL必须优化，添加合适索引
- Extra中的Using filesort和Using temporary是优化重点
- rows扫描行数过大需警惕，通过索引减少扫描范围
- 结合业务场景，不要过度优化（如小表全表扫描可能更快）
总结
执行计划分析的核心是”找瓶颈、加索引、减扫描“，重点关注type、key、rows、Extra四个字段，配合实际业务数据量和查询频率，制定针对性的优化策略。在面试中能快速定位问题并给出优化思路，是数据库优化能力的体现。