【性能优化必备】MySQL 执行计划 EXPLAIN

当你发现某条 SQL 查询慢得让人怀疑人生时，你会怎么做？

👉 加索引？删索引？重写 SQL？

其实，这些都不能盲目操作。
第一步永远应该是：分析 SQL 的执行计划（EXPLAIN）。

一、什么是执行计划？

数据库执行一条 SQL 前，会评估各种执行方案，然后选择一个它认为“最便宜”的方式。

而 실행这个计划的内容，就是 EXPLAIN 告诉你的。

你可以把它理解成：

MySQL 告诉你：
“这条 SQL 我打算怎么跑，我会走哪个索引，我扫描多少行，你自己看看行不行。”

使用方法非常简单：

   EXPLAIN SELECT * FROM user WHERE name = 'Tom';

执行后你会看到一张关键指标表。

二、EXPLAIN 输出字段逐条讲透

执行计划的核心在于理解每一个列的意义。

下面逐条解释最重要的指标。

1、 type — 决定查询好坏的最核心指标之一！

表示 MySQL 扫描数据时采用的方式，效率从高到低如下：

👉 一句话总结：

type 越靠前越好，出现 ALL 基本就慢了。

2、 possible_keys 与 key

• • possible_keys：可能会使用的索引
• • key：实际使用的索引

如果 key 为 NULL…

👉 你写的这条 SQL 很可能没用到索引！

3、 key_len（索引使用长度）

表示 MySQL 实际使用了联合索引的哪些字段。

例如你有索引 (name, age, city)
如果 key_len 只对应 name 的长度：

👉 说明只用到了第一个字段（很可能违反了最左前缀原则）

4、 rows（扫描行数）

表示 MySQL 预计要扫描多少行。

👉 rows 越大，SQL 越慢。

如果看到：

   rows: 100000

你就知道问题所在了。

5、 Extra（隐藏的重要信息）

常见关键提示：

如果出现：

   Using temporary
Using filesort

👉 一定要优化！这是性能杀手！

三、实战：一条 SQL 从慢到快的进化

假设你有 SQL：

   SELECT * FROM order WHERE user_id = 10001 ORDER BY create_time DESC;

执行计划可能是：

   type: ALL
key: NULL
Extra: Using filesort

问题点非常明显：

❌ 全表扫描
❌ 无索引
❌ 排序还 filesort

索引优化：

   CREATE INDEX idx_user_time ON order(user_id, create_time);

查看执行计划：

   type: ref
key: idx_user_time
Extra: Using index

👉 瞬间从几十毫秒提升到 1 毫秒以内！

四、如何正确使用 EXPLAIN 优化 SQL？

牢记四步法：

1、 确认是否走了索引

看 key 是否为 NULL。

2、 查看扫描行数 rows

rows 越大，性能越差。

3、 看是否出现 Using filesort / Using temporary

出现了就说明 ORDER BY 或 GROUP BY 有问题。

4、 看 type，尽量不让它低于 range

ref / const 最理想。

五、总结

EXPLAIN 是用来分析 MySQL 执行 SQL 时选择的执行计划。
核心关注字段为：type、key、key_len、rows、Extra。
type 决定扫描方式，从好到差依次是 const、ref、range、index、ALL。
key 是否为 NULL决定是否用到索引。
Extra 中的 Using filesort / Using temporary 是优化重点。
通过 EXPLAIN，可以判断 SQL 是否走索引、是否全表扫描，并找出性能瓶颈，指导索引优化。