MySQL EXPLAIN ANALYZE 里的 loops 怎么理解

第一次看到 MySQL EXPLAIN ANALYZE 输出里的 loops=100，很容易把它当成“返回了 100 行”。实际不是：loops 表示这个迭代器被执行了多少次，rows 才表示每次执行或汇总后返回的行数。读 JOIN 计划时，最有价值的做法是把 loops 放回父子节点关系中，看它是否被外层结果重复放大。

先看懂 loops 对应的执行层

MySQL 手册说明，EXPLAIN ANALYZE 会真正执行语句，并用 TREE 形式展示迭代器、耗时、实际返回行数和 loops。下面这段查询只用于观察一个索引范围扫描的输出结构，写入生产环境前要先确认查询本身不会带来不必要的负载。

-- 用 TREE 输出观察索引范围扫描的实际迭代次数
EXPLAIN ANALYZE FORMAT=TREE
SELECT id, status
FROM orders
WHERE customer_id = 42;

看到类似 (actual time=0.030..0.038 rows=2 loops=1) 时，可以这样读：该节点实际执行 1 次，返回 2 行；两个时间点分别描述首行和完成该节点的耗时。若 loops 大于 1，手册中的 actual time 通常是每次循环的平均耗时，不能直接把它当作整个节点的总耗时。

用嵌套循环判断 loops 是否放大

在 JOIN 计划里，内层节点可能会为外层的每一行重新执行。假设外层实际产生 100 行，而内层节点的 loops 也是 100，这通常说明内层被外层逐行驱动；它并不自动代表有问题，但应继续看内层每轮返回多少行、每轮耗时是多少，以及估算 rows 是否严重偏低。

-- 用一个明确的连接条件观察父子迭代器的对应关系
EXPLAIN ANALYZE FORMAT=TREE
SELECT o.id, c.level
FROM orders AS o
JOIN customers AS c ON c.id = o.customer_id
WHERE o.created_at >= '2026-01-01';

读树形输出时先找父节点，再沿缩进查看子节点。外层过滤后的实际 rows 可以作为内层 loops 的解释线索；如果外层实际 rows 远高于估算 rows，内层成本也可能被低估。相反，loops 很高但每轮几乎没有行、耗时也很低，未必值得优先优化。

从估算偏差回到排查动作

可以按“估算 rows → 实际 rows → loops → actual time”的顺序看。估算和实际相差很大时，先检查数据分布与统计信息；MySQL 手册也建议在怀疑索引选择不合理时运行 ANALYZE TABLE 更新键的基数等统计信息，再重新观察计划。

-- 更新优化器可能依赖的表统计信息，再重新获取实际计划
ANALYZE TABLE orders, customers;

-- 重新观察统计信息更新后的估算与实际差异
EXPLAIN ANALYZE FORMAT=TREE
SELECT o.id, c.level
FROM orders AS o
JOIN customers AS c ON c.id = o.customer_id
WHERE o.created_at >= '2026-01-01';

还要记住两个边界：EXPLAIN ANALYZE 会执行查询，不能把它当成零成本的静态 EXPLAIN；它使用 TREE 格式，FORMAT=JSON 和 FORMAT=TRADITIONAL 不适用于 EXPLAIN ANALYZE。优化目标也不应只是把 loops 压到 1，而是让实际数据量、访问路径和总耗时符合业务约束。

相关问题

loops 越大就一定越慢吗？

不一定。loops 需要和每轮返回行数、每轮平均耗时以及父节点实际行数一起看；小数据集上的高 loops 可能比一次昂贵扫描更轻。

rows 和 loops 应该先看哪个？

先沿树找到父子关系，再对比实际 rows 与 loops。对于嵌套循环，父节点实际 rows 往往是解释内层 loops 的关键线索。

为什么 EXPLAIN ANALYZE 不能用 JSON？

MySQL 8.4 的 EXPLAIN ANALYZE 只支持 TREE 输出；需要 JSON 结构时可单独使用 EXPLAIN FORMAT=JSON，但它不会提供同一份实际执行时序。