不会 explain 的后端，本质是在“猜数据库”

---

一、为什么很多后端优化 SQL，全靠“玄学”？

很多人优化 SQL 的方式是：

• 慢了 → 加索引
• 还慢 → 换写法
• 再慢 → 查博客
• 不行 → 再加索引

结果经常是：

• 索引越建越多
• 有的 SQL 快了，有的更慢了
• 自己也说不清为什么

本质问题只有一个：

👉 你不知道数据库“打算怎么查”。

而数据库真正决定性能的，不是 SQL 文本，而是：

👉 执行计划。

二、EXPLAIN 是什么？

一句后端版定义：

👉 EXPLAIN = 让 MySQL 把“执行计划”打印给你看。

你写：

SELECT * FROM t_order WHERE user_id = 123;

数据库脑子里已经决定了：

• 用不用索引
• 用哪个索引
• 扫多少行
• 要不要排序
• 要不要临时表

只是平时你看不到。

当你写：

EXPLAIN SELECT * FROM t_order WHERE user_id = 123;

👉 数据库会把它的“作战方案”给你。

所以可以非常直白地说：

👉 EXPLAIN 是后端和数据库对话的语言。

三、EXPLAIN 结果长什么样？

执行 explain 后，你会看到一张类似这样的表（示意）：

+----+-------------+---------+------+--------------------------+---------------------+------+-------+--------+-----------------------------+
| id | select_type | table   | type | possible_keys            | key                 | ref  | rows   | Extra                       |
+----+-------------+---------+------+--------------------------+---------------------+------+-------+--------+-----------------------------+
|  1 | SIMPLE      | t_order | ref  | idx_user,idx_user_status | idx_user_status_ct  | const| 85000  | Using where; Using filesort |
+----+-------------+---------+------+--------------------------+---------------------+------+-------+--------+-----------------------------+

这张表不是“结果”，
而是：

👉 数据库准备怎么干活。

四、当前阶段，后端只需要盯死 4 个字段

你不用一上来把 explain 所有列都背下来。
真正干活，80% 的判断来自 4 列。

1️⃣ key —— 用了哪个索引（第一眼必看）

key = idx_user_status_ct

含义：

👉 数据库最终选用的索引。

危险信号：

key = NULL
 

👉 基本等价于：没走索引 / 全表扫描。

后端第一反应应该是：

👉 这条 SQL 有结构性问题。

2️⃣ rows —— 预计扫描多少行（工作量指标 ⭐）

rows = 85000

这是 explain 里最有价值的列之一。

它在告诉你：

👉 数据库觉得自己要“干多少活”。

一个非常实用的后端直觉：

• rows = 1 → 极好
• rows = 几十 → 很好
• rows = 几百/几千 → 可以
• rows = 几万 → 大概率慢
• rows = 几十万+ → 事故现场

👉 SQL 优化，本质就是：把 rows 打下来。

3️⃣ type —— 访问方式（效率等级）

你现在阶段，只要认识这三个就够：

• const / eq_ref → 主键 / 唯一索引（最好）
• ref / range → 普通索引（常见）
• ALL → 全表扫描（高危）

如果你看到：

type = ALL

👉 后端条件反射：
“这条 SQL 必须改。”

4️⃣ Extra —— 有没有额外折磨数据库

常见你一定要有感觉的几个：

• Using where → 有条件过滤（正常）
• Using filesort → 排序没走索引
• Using temporary → 用了临时表（危险信号）
• Using index → 覆盖索引（加分项）

特别是：

👉 filesort + rows 很大
👉 temporary + rows 很大

基本就是慢 SQL 的标准形态。

五、一个典型慢 SQL 的 explain 画面

EXPLAIN
SELECT *
FROM t_order
WHERE user_id = 123
ORDER BY create_time DESC;

你可能看到：

• key：idx_user
• rows：200000
• Extra：Using filesort

后端该怎么解读？

👉 用 user_id 索引扫了 20 万行
👉 再额外排序
👉 性能瓶颈不在 SQL 语法，而在“扫描量 + 排序方式”

六、一个健康 SQL 的 explain 画面

EXPLAIN
SELECT id, status, create_time
FROM t_order
WHERE user_id = 123 AND status = 1
ORDER BY create_time DESC
LIMIT 20;

理想状态会接近：

• key：idx_user_status_ct
• rows：20～50
• Extra：Using where

后端看到这种 explain，应该有直觉：

👉 扫描量接近返回量
👉 排序走了索引
👉 这条 SQL 结构是健康的。

七、Explain 驱动 SQL 优化的标准流程

真正专业的 SQL 优化，从来不是“改一句试试”。

而是：

① explain

👉 看执行计划

② 找问题

• 用没用索引？
• 扫描行数大不大？
• 有没有 filesort / temporary？

③ 针对性调整

• 设计/调整索引
• 改 where / order by 结构
• 改分页方式
• 收敛字段（少 select *）

④ 再 explain 验证

👉 这是后端数据库优化的工程闭环。

八、为什么说 Explain 才是“真正的 SQL 语言”？

因为：

• SQL 是你写给数据库看的
• explain 是数据库写给你看的

SQL 告诉数据库：你想要什么。
Explain 告诉你：它打算怎么给。

👉 当你开始看 explain，你关注的就不再是“语句”，
👉 而是“执行方式”。

这正是后端能力和“会写 SQL”的本质区别。

九、这一篇你真正要记住的只有一句话

👉 SQL 优化不是调语法，而是用 explain 控制数据库的执行路径。