MySQL EXPLAIN ANALYZE 中 actual time 两个数怎么读

我第一次看 MySQL `EXPLAIN ANALYZE` 的 TREE 输出时，最容易误读的就是这一行：`(actual time=0.0168..0.0182 rows=1 loops=1)`。两个小数点不是“开始时间和结束时间”，也不是把整条 SQL 切成两个阶段。

更准确的读法是：第一个数表示这个迭代器返回第一行所花的时间，第二个数表示该迭代器的执行耗时；单位是毫秒。第二个时间包含子迭代器的工作，但不包含父迭代器的工作；如果一个迭代器执行了多轮，这个时间是每轮平均值。本文用一条只读查询把这几个概念串起来。

官方参考地址：`https://dev.mysql.com/doc/refman/8.4/en/explain.html`

先搭一个只读诊断场景

为了避免把复杂业务 SQL 的所有细节混在一起，我通常先准备一个带过滤、排序和限制条数的查询。下面的表结构只是诊断示例，重点不在表设计，而在如何阅读执行树。

CREATE TABLE orders (
    id BIGINT PRIMARY KEY,
    user_id BIGINT NOT NULL,
    status VARCHAR(20) NOT NULL,
    created_at DATETIME NOT NULL,
    amount DECIMAL(10, 2) NOT NULL,
    KEY idx_status_created (status, created_at)
);

-- 只分析查询，不把写入语句带进实验环境。
EXPLAIN ANALYZE FORMAT=TREE
SELECT id, user_id, amount
FROM orders
WHERE status = 'paid'
  AND created_at >= '2026-01-01'
ORDER BY created_at
LIMIT 20\G

`EXPLAIN ANALYZE` 与普通 `EXPLAIN` 的一个重要区别是：它会运行被分析的语句，并在执行计划上补充实际计时、实际返回行数和循环次数。因此，生产环境先确认语句是只读的，并控制查询范围；不要把它当成完全不触发业务执行的静态检查。

它使用 TREE 格式展示迭代器节点。你可能会看到类似下面的示意输出，数值用于说明阅读方式，不代表这条示例 SQL 在你的库上必然得到相同结果：

-> Limit: 20 row(s)
    (actual time=0.033..0.042 rows=20 loops=1)
    -> Index range scan on orders using idx_status_created
        (actual time=0.030..0.0384 rows=20 loops=1)

拆开 actual time 的两个数

把 `actual time=a..b` 拆开看，最实用的记忆方式是：

• `a`：该迭代器把第一行交给父节点或消费者之前，等待了多久。
• `b`：该迭代器完成自身执行所记录的时间，包含它等待子迭代器产生数据的部分，但不包含父节点后续处理的部分。

例如 `actual time=0.0168..0.0182`，可以先读成“约 0.0168 毫秒拿到第一行，约 0.0182 毫秒完成这个迭代器的一轮执行”。它不是 `0.0182-0.0168` 的单独耗时，也不能把所有节点的第二个数直接相加当成整条 SQL 的总耗时。

这两个数还要和 `rows`、`loops` 一起看。`rows=20` 表示这个节点实际返回了 20 行，`loops=1` 表示只执行了一轮；如果只盯着时间而忽略行数，很容易把“少量数据很快”误判成“访问路径一定合理”。

沿父子节点读执行阶段

执行树的缩进不是装饰。上面的 `Index range scan` 是子迭代器，`Limit` 是父迭代器。读一个节点时，我会先看最深处的子节点，再回到父节点，问两个问题：子节点什么时候给出第一行？父节点在拿到这些行后又做了什么？

官方对第二个时间的定义包含子迭代器、但不包含父迭代器。所以父节点的时间可以比子节点更长，这通常意味着父节点还承担过滤、排序、限制或连接等工作；但不要据此把父子时间重复相加。它们描述的是树上不同节点的观测范围，不是互不重叠的计时片段。

实际排查中，如果子节点的 `b` 已经明显偏大，优先检查访问路径、扫描范围和统计信息；如果子节点很快而父节点明显变慢，再看父节点承担的过滤、排序、连接或行数放大。这样比看到一个“大时间”就直接加索引更稳。

把 loops 与行数一起判断

当 `loops=1` 时，时间区间比较直观；当 `loops` 大于 1 时，MySQL 文档说明对应耗时是每轮平均时间。比如一个嵌套循环的子节点显示 `actual time=0.12..0.30 rows=4 loops=100`，应该理解为“每轮平均约 0.30 毫秒、每轮返回 4 行、共执行 100 轮”，而不是说整棵树只花了 0.30 毫秒。

-> Nested loop inner join
    (actual time=0.20..35.00 rows=400 loops=1)
    -> Index lookup on users
        (actual time=0.01..0.02 rows=1 loops=100)
    -> Index lookup on orders
        (actual time=0.12..0.30 rows=4 loops=100)

这类输出不能只看一条记录的时间。先确认哪个节点的 `loops` 很大，再把平均时间与返回行数放在一起看；“每轮很快”乘以“大量循环”同样可能形成明显的总成本，但父节点、子节点和等待关系仍然不能简单重复相加。

形成一张排查速查表

我会按下面的顺序做第一次判断：

最后再强调一次边界：`actual time=a..b` 的两个数是节点级执行信息，不是应用端从发起请求到收到响应的完整耗时。网络、连接池、锁等待、结果传输和客户端处理，都可能出现在 SQL 之外。若要定位端到端慢，还需要把数据库计划与应用侧耗时分开记录。

常见问题

actual time 的第二个数是不是整条 SQL 的总耗时？

不是。它是当前迭代器的执行耗时，包含子迭代器但不包含父迭代器。整条语句应结合根节点、所有节点的层级和应用端测量来判断。

两个数相减是不是“返回剩余行”的时间？

不是。相减只能得到两个记录值的差，不能把它当作 MySQL 额外定义的第三个指标。阅读时先把第一个数看成首行时间，把第二个数看成该迭代器耗时。

loops 越大，第二个时间就一定越差吗？

不一定。第二个时间在多轮执行时是每轮平均值，真正的影响要结合循环次数、每轮行数和父节点的汇总结果一起看。