SQL 执行慢？别急着加索引，先看 Explain 执行计划
SQL 执行慢？别急着加索引，先看 Explain 执行计划
慢 SQL 不是玄学。每条慢查询背后，都有一个明确的"罪魁祸首"。
而找出它的第一步，不是改代码，是执行一句EXPLAIN。
先学会看这张表
执行EXPLAIN SELECT ...，你会得到一张结果表。
只看这几列就够了：
| 列名 | 含义 | 什么值是好的 |
|---|---|---|
type | 访问类型，决定了查询方式 | const>eq_ref>ref>range>index>ALL |
key | 实际用了哪个索引 | 有索引名，别是NULL |
rows | 扫描了多少行 | 越少越好 |
Extra | 额外信息，藏着很多坑 | 见下文详解 |
一、type：最关键的一列
它直接告诉你数据库是怎么找数据的。
从好到差排个序：
| type | 含义 | 评价 |
|---|---|---|
system | 只有一行，表只有一条记录 | 极好，几乎不会慢 |
const | 主键或唯一索引等值查询 | 极好，一步到位 |
eq_ref | 唯一索引关联查询 | 很好 |
ref | 非唯一索引等值查询 | 良好，大多数场景够用 |
range | 索引范围扫描（BETWEEN、>、IN） | 可接受 |
index | 全索引扫描，不回表 | 数据量小可以，大了就慢 |
ALL | 全表扫描 | 这就是慢的根源 |
一句话：
type到达ALL，说明没用索引，优先优化这里。
二、rows：扫描了多少行
这个数字越小越好。
rows = 1：精准命中，完美。rows = 几百：还行，看场景。rows = 几万/几十万：大概率要出问题。
关键对比：
rows = 10, 实际返回 10 行 → 健康 rows = 100000, 实际返回 1 行 → 严重浪费，索引没选对扫描行数和返回行数差距越大，说明索引越没用到位。
三、Extra：最容易忽略的"暗号"
这一列藏着真正的排查线索。
| 值 | 含义 | 怎么处理 |
|---|---|---|
Using index | 覆盖索引，不用回表 | ✅ 最佳状态，不用改 |
Using where | 存储引擎层过滤后，Server 层还要再过滤 | ⚠️ 索引不够精准 |
Using index condition | 索引下推（ICP），5.6+ 支持 | ✅ 还不错 |
Using filesort | 需要额外排序，没用上索引排序 | ❌ 加索引或改ORDER BY |
Using temporary | 用了临时表，常见于GROUP BY/DISTINCT | ❌ 优化分组逻辑或加索引 |
Using join buffer | 用了 Join Buffer，没走索引关联 | ❌ 被驱动表没索引，补上 |
出现
Using filesort或Using temporary，90% 的情况是索引没建对。
四、实战：一条慢 SQL 怎么拆
假设这条 SQL 跑了 8 秒：
sql
SELECT u.name, o.amount FROM users u JOIN orders o ON u.id = o.user_id WHERE o.created_at > '2026-01-01' ORDER BY o.amount DESC LIMIT 10;执行EXPLAIN，结果：
| id | select_type | table | type | key | rows | Extra |
|---|---|---|---|---|---|---|
| 1 | SIMPLE | o | ALL | NULL | 500000 | Using where; Using filesort |
| 1 | SIMPLE | u | eq_ref | PRIMARY | 1 | — |
诊断：
orders表type = ALL，全表扫描 50 万行 →没用索引。Extra = Using filesort，排序没用上索引 →ORDER BY没索引支撑。
优化：
sql
-- 给 orders 表加联合索引 ALTER TABLE orders ADD INDEX idx_created_amount (created_at, amount DESC);再看EXPLAIN：
| table | type | key | rows | Extra |
|---|---|---|---|---|
| o | range | idx_created_amount | 320 | Using index condition |
| u | eq_ref | PRIMARY | 1 | — |
type从ALL变成range。rows从 50 万降到 320。Extra出现Using index condition，不再filesort。
8 秒 → 0.01 秒，就改了一个索引。
五、排查流程（记住这条链路）
SQL 慢 └─ EXPLAIN 看 type ├─ type = ALL → 没走索引，查 key 列，补索引 ├─ type = index → 全索引扫描，看是否需要回表 └─ type 够好但仍慢 → 看 rows 和 Extra ├─ Using filesort → ORDER BY 没索引 ├─ Using temporary → GROUP BY 没索引 └─ Using join buffer → 被驱动表缺索引最后一句话
慢 SQL 的答案，80% 藏在
EXPLAIN的type和Extra里。先看执行计划，再动手改，别上来就加索引。