用 EXPLAIN ANALYZE 拆解 MySQL 查询的真实耗时

排查 MySQL 慢查询时，EXPLAIN 给的是优化器的预估，而 EXPLAIN ANALYZE 会真正执行一条可分析语句，并在 TREE 计划中补充实际耗时、返回行数和循环次数。我的经验是先看“预估行数和实际行数是否偏离”，再看哪个迭代器的 actual time 被循环放大；只盯着最外层总时间，往往会错过真正的扫描或连接瓶颈。

官方文档：https://dev.mysql.com/doc/refman/8.4/en/explain.html

一、先把预估计划和真实执行分开

先用一个只读查询建立基线。下面的表名和数据量只是示例，重点是让过滤条件、连接关系和返回列保持稳定，方便前后比较：

-- 先看优化器如何估算订单与用户的连接，不会执行 SELECT
EXPLAIN FORMAT=TREE
SELECT u.id, COUNT(*) AS paid_orders
FROM app_user AS u
JOIN orders AS o ON o.user_id = u.id
WHERE o.status = 'paid'
  AND o.created_at >= '2026-10-01'
GROUP BY u.id;

-- 在测试库中测量真实迭代器耗时；该语句会执行查询本身
EXPLAIN ANALYZE
SELECT u.id, COUNT(*) AS paid_orders
FROM app_user AS u
JOIN orders AS o ON o.user_id = u.id
WHERE o.status = 'paid'
  AND o.created_at >= '2026-10-01'
GROUP BY u.id;

两条语句的差别很关键：普通 EXPLAIN 主要回答“准备怎么做”，EXPLAIN ANALYZE 回答“实际做下来每个迭代器花了什么代价”。在生产库上不要把后者当成无副作用的计划查询，先确认语句类型、锁影响和数据范围。

二、沿 TREE 计划读取真实耗时

MySQL 8.4 的 EXPLAIN ANALYZE 输出通常包含 cost、预估 rows，以及 actual time、实际 rows、loops。阅读顺序建议从最内层扫描开始，再向上看过滤、连接、聚合：内层一次多做一点工作，外层的循环可能把这点成本放大很多。

例如某个索引查找显示 actual time=0.4..18.6 rows=1200 loops=30，不能只把 18.6 毫秒理解为一次查询的总成本。它提示这个节点在外层连接中重复运行，应该继续核对上层节点的连接顺序与过滤条件。

三、用预估与实际的偏差定位问题

真正有价值的不是“实际耗时很大”这一结论，而是找到偏差来源。可以把每个节点按下面三种情况分类：

• rows 预估远小于实际：优化器低估了数据量，可能是列分布变化、条件选择性差或统计信息过期。先记录计划，再在维护窗口评估 ANALYZE TABLE。
• rows 接近但 time 很高：估算数量没错，单行访问、回表、磁盘读、表达式计算或聚合本身可能昂贵。
• 内层 rows 不大但 loops 很高：优先检查嵌套循环的驱动表和连接键，避免每个外层行都重复做低效扫描。

-- 仅在确认统计信息需要更新时执行；会刷新表的键分布统计
ANALYZE TABLE orders;

-- 更新后重新观察计划，避免只凭一次测量下结论
EXPLAIN ANALYZE
SELECT u.id, COUNT(*) AS paid_orders
FROM app_user AS u
JOIN orders AS o ON o.user_id = u.id
WHERE o.status = 'paid'
  AND o.created_at >= '2026-10-01'
GROUP BY u.id;

ANALYZE TABLE 不是“慢了就必做”的万能修复。更新前后要保存 rows、loops 和关键访问路径的变化，只有计划更接近真实分布且测量稳定，才值得继续改索引或改写 SQL。

四、用第二次测量确认优化方向

定位到慢节点后，一次只改一个变量：例如为连接和时间过滤补充合适的联合索引，或者先缩小派生结果集，再重新运行同一条 EXPLAIN ANALYZE。比较时至少记录以下四项：

如果要比较两种索引方案，先固定参数、数据范围和缓存条件；如果要观察冷缓存或磁盘影响，则明确记录这是另一组实验。EXPLAIN ANALYZE 给的是一次执行剖面，不代表所有并发、缓存和参数组合下的平均延迟。

相关问题

EXPLAIN ANALYZE 会不会真正执行 SQL？

会。它不是纯计划展示命令，因此要在测试数据或已确认安全的只读语句上使用，并注意执行时间与资源消耗。

actual time 的两个数字分别是什么？

通常表示该迭代器产生第一行到完成输出的时间范围，单位是毫秒；存在多个循环时，文档说明时间按循环给出平均值。

为什么 rows 估算准确，查询仍然很慢？

行数只是工作量的一部分。随机 I/O、回表、表达式、排序、聚合和高循环次数都可能让实际耗时升高，要继续沿 TREE 计划定位。