昨天我们聊了如何通过慢查询日志定位“谁慢了”，今天就来解决下一个关键问题：它为什么慢？

答案就在 EXPLAIN 这个命令里。这几乎是数据库工程师面试的必考题，也是日常工作中排查性能问题的核心工具。能把执行计划里的 type 和 Extra 聊明白，面试官基本就能确定你是真干过活的。

怎么用

使用起来很简单，在查询语句前加上 EXPLAIN 即可：

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

这里有个细节需要注意：标准的 EXPLAIN SELECT 只生成执行计划，不实际执行查询。但 EXPLAIN ANALYZE 会真实地跑一遍查询，并给出实际耗时，代价是它会获取元数据锁（MDL），在并发执行DDL操作时可能引发锁等待。

type：你怎么找的数据？

这是执行计划里最核心的一列，直接反映了MySQL访问数据的方式。其效率从高到低排列如下：

面试时经常被问到type的排序。简单来说，看到 ALL 和 index 就要提高警惕了——当然，对于几十行的小字典表，全表扫描也无伤大雅；但如果是在百万级的大表上出现 ALL，那基本可以断定索引没起作用。

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

这一列显示的是优化器估算需要扫描的行数，并非精确值。它的价值在于看比例。

比如，rows显示500000，而你预期只返回几十行数据，这通常意味着索引可能有问题，或者查询条件没能有效利用索引。如果估算值和实际返回行数差距过大，很可能是表的统计信息过时了，这时可以执行一下 ANALYZE TABLE 来更新。

Extra：亮点都在这里

Extra列提供了执行计划的额外信息，很多性能优化的线索都藏在这里。

一个简单的判断标准是：type 达到 ref 或 range 以上，并且 Extra 列不包含 filesort 或 temporary，这样的执行计划通常就是健康的。

实战：看个例子

光说不练假把式，来看一个具体的例子：

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

假设执行计划输出如下，那简直是亮起了三盏红灯：

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

瓶颈在哪？ MySQL需要把50万行数据全部读入内存，逐行筛选出 status='pending' 的记录，然后在内存或磁盘中对结果集进行排序（filesort），最后才取出前10条。这相当于经历了全表IO、内存过滤、排序三重开销，效率可想而知。

修复：加一个复合索引

针对上面的查询，一个立竿见影的优化是添加复合索引：

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

为什么索引字段顺序是 (status, created_at)？ 这利用了B+树索引的特性。索引的叶子节点会按照定义字段的顺序（先status，再created_at）天然有序存储。这意味着：

1. MySQL可以通过 status='pending' 快速定位到索引中对应的片段，避免全表扫描。
2. 这个片段内部的数据已经按照 created_at DESC 排好序了，因此可以完全省略 filesort 操作。
3. 直接按顺序取前10条记录即可返回。

加上索引后再看执行计划：

type: ref
rows: 50
Extra: Using where

• 扫描量：从50万行骤降到50行，效率提升1万倍。
• 排序开销：filesort 彻底消失。
• 唯一代价：由于查询是 SELECT *，MySQL还需要根据主键回表去获取其他字段（如name、price等）的数据。

为什么 “Using where” 还在，却反而更好了？

这里有个常见的误区：很多人一看到 Extra: Using where 就紧张。其实它只是一个中性标记，仅仅表示“Server层会使用WHERE条件进行过滤”。真正决定性能的是：它需要在多少行数据上进行过滤，以及是否伴随着其他高开销操作。

所以，“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 则是健康的。

再进一步：覆盖索引

如果业务上只需要 status 和 created_at 这两列，我们可以把查询改写为：

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

此时的执行计划会变成：

Extra: Using where; Using index

看到了吗？Using index 出现了。这意味着连回表操作都省了——索引的叶子节点里已经包含了查询所需的全部数据（status和created_at），MySQL无需再去访问主键索引。这就是覆盖索引带来的极致性能。

面试解答

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

多数情况下，index 比 ALL 要好一点，因为索引文件通常比数据文件小，遍历索引的IO开销更少。但是，当查询不能使用覆盖索引且需要回表时，type: index 反而可能比 ALL 更差。原因在于，全扫描索引树会产生大量随机I/O去回表查询数据，其性能可能还不如顺序读取整个数据文件的 ALL 类型。所以，不能孤立地看type，必须结合Extra里是否有 Using index 一起判断。

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

不一定。如果排序的数据量小于 sort_buffer_size 参数设置的大小，排序会在内存中完成。只有当数据量超过这个阈值时，MySQL才会使用磁盘临时文件进行外部排序。但无论如何，出现 Using filesort 都是一个需要关注的信号，意味着排序无法通过索引完成。

️ 几个坑

• EXPLAIN 是估算：它展示的是优化器预估的执行计划，EXPLAIN ANALYZE 才是真实执行后的结果。
• 参数绑定影响计划：使用预处理语句（如 WHERE id = ?）时，优化器可能无法准确选择索引。分析时，最好用具体的值代替占位符来查看执行计划。

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

理论学习之后，实战训练至关重要。如果没有现成的慢查询，可以借助AI来模拟场景。

玩法一：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

练习几轮后，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