别再盯着EXPLAIN的rows列了，8.0.18之后有更好的选择

大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！

前两天一个同事跑过来问我：“小耶，你看这个执行计划，type是ref，rows是1000，Extra里用了索引，为啥还是慢？”

我看了眼SQL，又看了眼他的执行计划，问了一句：“你用的是EXPLAIN还是EXPLAIN ANALYZE？”

他说：“EXPLAIN啊，用了十几年了。”

——问题就出在这儿。

EXPLAIN给你看的是“优化器的预测”，不是“实际执行的结果” 。优化器说rows=1000，实际可能扫了100万行；优化器说用索引，实际可能回表回了10万次。

MySQL 8.0.18开始引入的EXPLAIN ANALYZE，直接把实际执行时间和实际行数输出给你看，把执行计划分析这件事从“猜”变成了“看”。

一、传统EXPLAIN的局限

传统的EXPLAIN输出，你看到的是：

rows=1000 —— 这是优化器估算的需要扫描的行数，不是实际扫描的行数。

如果统计信息过期、数据分布倾斜、或者优化器的基数估算出了偏差，这个数字可能和实际情况差一个数量级。

你基于一个错误的估算去优化，方向可能从一开始就偏了。

二、EXPLAIN ANALYZE带来了什么

EXPLAIN ANALYZE实际上会执行SQL（是的，它会真的跑一遍），然后输出每个执行步骤的实际执行统计信息：

EXPLAIN ANALYZE
SELECT * FROM orders WHERE user_id = 12345 AND create_time > '2026-01-01';

输出示例（MySQL 8.0+）：

-> Filter: (orders.create_time > '2026-01-01')  (cost=1234 rows=1000) (actual time=0.5..45.2 rows=856 loops=1)
    -> Index lookup on orders using idx_user_id (user_id=12345)  (cost=1234 rows=1000) (actual time=0.4..42.1 rows=12345 loops=1)

关键差异：

在上面这个例子里，优化器估算rows=1000，实际扫描了rows=12345——差了12倍。如果你只看传统EXPLAIN，可能觉得“只扫1000行，没问题”，但实际上回表回了1万多行，慢是必然的。

三、怎么用EXPLAIN ANALYZE定位问题

第一步：找到最慢的那个步骤

actual time告诉你每个步骤实际花了多少毫秒。哪一步时间最长，哪一步就是瓶颈。

第二步：对比估算值和实际值

如果rows和actual rows差距很大（比如差10倍以上），说明统计信息可能过期了——先更新统计信息，再看看执行计划有没有变化。

第三步：看loops

loops表示这个步骤被执行了多少次。如果loops很大（比如>1000），说明有大量的重复执行——可能是嵌套循环连接（Nested Loop Join）的驱动表选错了，或者子查询被反复执行。

四、注意事项

• EXPLAIN ANALYZE会实际执行SQL，所以不要在写操作上直接跑——先在测试环境或只读从库上验证

• 对于耗时很长的SQL，EXPLAIN ANALYZE本身也要跑那么久，要有耐心

• MySQL 5.7及以下版本不支持，需要升级到8.0.18+

• EXPLAIN ANALYZE的输出比传统EXPLAIN详细得多，需要花时间熟悉格式

五、小结

EXPLAIN用了十几年，是时候升级到EXPLAIN ANALYZE了。前者给你看“优化器的预测”，后者给你看“实际执行的结果”。从“猜”到“看”，这是执行计划分析这件事上最大的认知升级。

小耶在手，SQL 不愁

还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~