你是不是也遇到过这样的场景：线上系统突然卡顿，业务方疯狂催你，你抓出一条慢SQL，复制到客户端执行确实很慢，但加个EXPLAIN一看，输出一堆字段——type、key、rows、Extra——瞬间懵了。

别慌。今天我用10年DBA经验告诉你，看懂执行计划只要盯着4个关键指标。直接用案例说话，不扯理论。

一、执行计划到底看什么？

执行计划就是数据库执行SQL的“路线图”。你不需要背所有字段，先盯死这四个：

只要这四个里有一个亮红灯，慢查询的元凶基本就锁定了。

二、实战案例一：全表扫描引发的血案

场景：报表查询从2秒变成20秒

电商运营反馈：“订单报表越查越慢，现在点一下要等十几秒！”

SQL长这样：

SELECT * FROM orders WHERE create_time BETWEEN '2024-01-01' AND '2024-12-31'ORDER BY order_id DESC LIMIT 1000;

执行EXPLAIN：

EXPLAIN SELECT * FROM orders WHERE create_time BETWEEN '2024-01-01' AND '2024-12-31'ORDER BY order_id DESC LIMIT 1000;

输出结果：

type: ALLkey: NULLrows: 21456789Extra: Using where; Using filesort

元凶锁定：

• type=ALL：全表扫描，2千万行数据硬扫
• key=NULL：没走索引
• rows=2100万：扫描行数触目惊心
• Extra=Using filesort：文件排序，雪上加霜

直接开刀：

-- 创建复合索引，覆盖查询条件CREATE INDEX idx_orders_createtime_orderid ON orders(create_time, order_id DESC);

优化后再看：

type: rangekey: idx_orders_createtime_orderidrows: 8546Extra: Using where; Using index

结果： 扫描行数从2100万降到8546，查询从12秒变成200毫秒。

三、实战案例二：排序引发的“惨案”

场景：分页查询越来越慢

订单列表分页，用户翻到后面卡死。

SQL长这样：

SELECT order_id, buyer_id FROM tcorder WHERE buyer_id = 123456 ORDER BY create_time DESC, order_id ASC LIMIT 0, 10;

执行EXPLAIN：

type: refkey: idx_buyer_idrows: 8705Extra: Using where; **Using filesort**

元凶锁定：

• type=ref：走了索引，不错
• key=idx_buyer_id：用了buyer_id索引
• Extra=Using filesort：排序没走索引！

为什么？ 排序字段create_time在索引里，但order_id不在同一个索引里，导致无法利用索引排序，只能内存或磁盘排序。

优化方案：

-- 重建复合索引，把排序字段加进去CREATE INDEX idx_buyer_createtime_orderid ON tcorder(buyer_id, create_time DESC, order_id ASC);

优化后再看：

type: refkey: idx_buyer_createtime_orderidrows: 22Extra: Using where; **Using index**

关键变化： Using filesort消失了，排序直接走索引，CPU消耗降低90%。

四、EXPLAIN“四看”口诀

看不懂记不住？用这个口诀：

• type一看是ALL，全表扫描跑不掉
• key一看是NULL，赶紧建索引别耽误
• rows一看上百万，数据量大要玩完
• Extra一看filesort，排序没走索引路

只要这四个没问题，你的SQL基本不会慢。

五、写在最后

很多开发同学觉得EXPLAIN难，其实90%的慢查询问题都出在索引上。你不需要搞懂所有字段，上面这四个看明白，80%的性能问题你都能自己解决。

最后送大家一句话：写SQL之前先想索引，写完之后EXPLAIN看一眼——养成这个习惯，你就是团队里的SQL优化专家。

你在工作中遇到最奇葩的慢查询是什么？评论区分享，我帮你“诊断”！