> EXPLAIN 执行计划解读 —— type/key/rows/Extra

---

大家好，我是一名拥有10年以上经验的DBA老兵，没有那多。

做这个系列，源于一个朴素的愿望：把踩过的坑、总结的经验系统化输出，希望能帮到刚入行或想进阶的兄弟们。

让我们开始今天的第24天内容。

---

昨天讲了慢查询日志——找到"谁慢"。今天讲它的续篇：**看出为什么慢。**

答案就是 `EXPLAIN`。面试必问，工作必用。**能把 type 和 Extra 聊透，面试官会觉得你真干活。**

---

## 怎么用

```sql
EXPLAIN SELECT * FROM users WHERE age > 30;
-- MySQL 8.0+ 还支持
EXPLAIN FORMAT=TREE SELECT ...
EXPLAIN ANALYZE SELECT ...  -- 真的跑了，给实际耗时
```

`EXPLAIN SELECT` 只生成计划不跑数据。但 `EXPLAIN ANALYZE` 真的会跑。另外 EXPLAIN 会拿 MDL 锁，同时有 DDL 操作并发执行时会有锁等待风险。

---

## type：你怎么找的数据？

执行计划里**最核心的一列**。按效率从高到低排：

| type | 含义 | 什么情况 |
|------|------|----------|
| `const` | 最多返回一行，按主键/唯一索引查 | `WHERE id = 1` |
| `eq_ref` | 连表时每行匹配一行 | JOIN 走主键 |
| `ref` | 普通索引等值匹配 | `WHERE status = 'active'` |
| `range` | 索引范围扫描 | `BETWEEN`、`> <`、`IN` |
| `index` | 遍历索引树 | 比 ALL 好一点，还是遍历 |
| `ALL` | 全表扫描 | **最差的，应该避免** |

面试最爱问 type 排序。**出现 ALL 和 index 就要警惕**——极小字典表全表扫描没问题，大表上出现 ALL，就是没走索引。

---

## rows：优化器猜你要扫多少行

估算值，不是精确值。**价值在看比例。**

rows=500000 而你只预期几十行——索引有问题。如果估算和实际差距大，说明统计信息可能过时了，跑一下 `ANALYZE TABLE`。

---

## Extra：亮点都在这里

| Extra 值 | 含义 |
|----------|------|
| `Using index` | **覆盖索引**，不回表，效率极高 |
| `Using where` | WHERE 条件未完全被索引过滤，服务器层再判断 |
| `Using index condition` | 索引条件下推（ICP） |
| `Using filesort` | 无法用索引排序，需要关注 |
| `Using temporary` | 用了临时表，常见于 GROUP BY |
| `Using where; Using index` | **理想状态** |

**判断标准**：type 到 ref/range 以上，Extra 不含 filesort/temporary。

---

## 实战：看个例子

```sql
EXPLAIN SELECT * FROM orders
WHERE status = 'pending'
ORDER BY created_at DESC
LIMIT 10\G
```

输出里三个红色警报：

```
type: ALL                 -- 全表扫描
rows: 500000              -- 逐行比对
Extra: Using where; Using filesort  -- 还要在内存里排序
```

**瓶颈在哪？**  
MySQL 要先把 50 万行数据逐行读入内存，筛选出 `status='pending'` 的若干行，再对结果集做 `filesort` 排序，最后取前 10 条。IO + 排序 + 回表，三重开销。

---

### 修复：加一个复合索引

```sql
ALTER TABLE orders ADD INDEX idx_status_created (status, created_at);
```

**为什么是这个顺序？**  
B+ 树索引的叶子节点天然按 `(status, created_at)` 有序存储。这意味着：

1. 先通过 `status='pending'` 快速定位到索引片段（避免全表扫）
2. 该片段内部已经按 `created_at DESC` 排好序（直接省略 filesort）
3. 取前 10 条即可收工

再看执行计划：

```
type: ref
rows: 50
Extra: Using where
```

- **扫描量**：50 万 → 50，降了 **1 万倍**
- **排序开销**：filesort 直接消失
- **唯一代价**：`SELECT *` 还要根据主键回表查其他字段（name、price 等）

---

### 为什么 "Using where" 还在，却反而更好了？

很多人看到 `Extra: Using where` 就紧张，其实它只是个**中性标记**，表示 "Server 层会用 WHERE 条件做过滤"。真正决定性能的是：**它要在多少行上做过滤，以及是否伴随其他恶性操作**。

| 阶段 | 执行计划 | 实际含义 |
|------|---------|---------|
| **加索引前** | `type: ALL` + `rows: 500000` + `Using where; Using filesort` | 先把 **50 万行**逐行读入内存，Server 层逐行过滤；过滤完还要在内存里排序（filesort） |
| **加索引后** | `type: ref` + `rows: 50` + `Using where` | 索引直接定位到 **50 行**匹配数据，Server 层只在这 50 行上确认条件；**排序已经由索引的有序性完成**，filesort 消失 |

所以 **"Using where" 没变，但它工作的上下文彻底变了**：

- 优化前：它是**劳动密集型**——在 50 万行里大海捞针
- 优化后：它是**确认型**——索引已经把数据筛到 50 行了，Server 层只是做最终校验，而且**省掉了 filesort 和全表 IO**

> 如果看到 `Using where` 就慌，那覆盖索引里的 `Using where; Using index` 你怎么解释？后者可是最佳实践。

真正该警惕的 Extra 组合是 `Using where; Using filesort`（全表扫 + 文件排序），而不是 `Using where` 本身。**看 Extra 不能只看标签，要看它跟在什么 type 和 rows 后面。** `ALL + Using where` 是灾难，`ref + Using where` 是健康。

---

### 再进一步：覆盖索引

如果业务上只关心这两列，把查询改成：

```sql
SELECT status, created_at FROM orders
WHERE status = 'pending'
ORDER BY created_at DESC
LIMIT 10;
```

执行计划会变成：

```
Extra: Using where; Using index
```

此时**连回表都省了**——索引叶子节点里已经存了需要的全部数据，MySQL 不会再去碰主键索引。这就是**覆盖索引**。

---

**📝 面试解答**：

**Q: type=index 和 ALL 哪个更差？**

> 多数情况下 index 比 ALL 好一点——索引比数据文件小，遍历的 IO 更少。但索引不能覆盖且要回表时，`index` 反而比 `ALL` **更差**：全扫描索引树产生大量随机回表 I/O，不如 ALL 的顺序读。所以不能只看 type，要结合 Extra 是不是 `Using index` 一起判断。

**Q: Using filesort 一定会写磁盘吗？**

> 不一定。数据量小在 sort_buffer 内存排序，超过 `sort_buffer_size` 才写磁盘。但出现 filesort 就是需要关注了。

---

## ⚠️ 几个坑

- **EXPLAIN 是估算**，`EXPLAIN ANALYZE` 才是真实执行
- **参数绑定影响计划**，分析时用具体值代替 `?`

---

## 🤖 AI实战工具箱：让AI当你的EXPLAIN陪练

**玩法一：AI出题你来判**

跟 AI 说：

> 你现在是 MySQL 面试官。随机生成 5 个 EXPLAIN 输出，里面有好的有坏的。每次给我一个，我判断 type 和 Extra 有没有问题，你再告诉我对不对。最后总结我的水平。

AI 可能会出这样的题：

```
SQL: SELECT * FROM users WHERE status = 'active'
type: ref   key: status   rows: 500   Extra: NULL
```

或这样的题：

```
SQL: SELECT * FROM orders ORDER BY created_at DESC LIMIT 10
type: ALL   key: NULL   rows: 100000   Extra: Using filesort
```

练完 5 道，AI 会告诉你错了几道、哪类问题老是漏判。

**玩法二：没有数据库也能练**

手边没 MySQL？让 AI 模拟：

> 假设有一张订单表 orders(id, user_id, status, amount, created_at)，50 万行。status 有普通索引。给我 3 条查询加 EXPLAIN 输出，分析哪条最优、哪条最差、为什么。

AI 生成的执行计划虽然不真实，但**判断逻辑是一样的**。

---

## 思考题

> 🤔 互动时间：

1. 你的业务 SQL 里有没有 type=ALL 的？今天给了你什么思路？
2. `EXPLAIN ANALYZE` 和普通 EXPLAIN 什么区别？
3. Extra 出现 `Using filesort` 但 SQL 没写 ORDER BY，怎么查？

---

## 总结

> 🎯 **面试考点**

- **type 排序**：const > eq_ref > ref > range > index > ALL
- **rows 列**：估算值，看比例而非绝对值
- **Extra 核心**：`Using index`（好）、`Using filesort/temporary`（要优化）
- **EXPLAIN 是估算**，`EXPLAIN ANALYZE` 才是真实执行
- **调优标准**：type ≥ ref/range，Extra 不含 filesort/temporary

今天就试一下：找个你常用的查询，前面加 `EXPLAIN` 跑一遍。看一眼 type 和 Extra。如果 type=ALL 或 Extra=Using filesort——这就是你今天要优化的事。

**下期预告**：索引失效的典型场景 —— 面试必问！

---

*有问题欢迎评论区交流，明天见！*


做这个系列，源于一个朴素的愿望：把踩过的坑、总结的经验系统化输出，希望能帮到刚入行或想进阶的兄弟们。

【MySQL百日打怪升级第24天】EXPLAIN 执行计划解读 —— type/key/rows/Extra

本文详解MySQL执行计划核心字段：type（访问类型，ALL/index需警惕）、rows（扫描行数，重在比例）、Extra（性能关键，关注Using index/filesort等）。结合实战案例与索引优化技巧，助DBA及开发者快速定位慢查根源，直击面试高频考点。

后端

数据库

职业发展

EXPLAIN执行计划核心指标解读：type列从const到ALL效率递减，重点关注ref/range以上级别；rows为估算扫描行数；Extra中的Using index表示覆盖索引优化，而Using filesort/temporary需警惕。通过复合索引(status, created_at)案例分析，展示如何将全表扫描优化为索引扫描，消除排序开销。掌握type与Extra组合分析，可快速定位SQL性能瓶颈，实现万倍查询优化。

服务器

MySQL

腾讯云数据库特惠，新用户首单0.5折起


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

EXPLAIN执行计划核心指标解读：type列从const到ALL效率递减，重点关注ref/range以上级别；rows为估算扫描行数；Extra中的Using index表示覆盖索引优化，而Using filesort/temporary需警惕。通过复合索引(status, created_at)案例分析，展示如何将...

【MySQL百日打怪升级第24天】EXPLAIN 执行计划解读 —— type/key/rows/Extra-腾讯云开发者社区-腾讯云

【MySQL百日打怪升级第24天】EXPLAIN 执行计划解读 —— type/key/rows/Extra

【MySQL百日打怪升级第24天】EXPLAIN 执行计划解读 —— type/key/rows/Extra

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐