MySQL EXPLAIN ANALYZE 怎么判断实际行数偏差

慢查询排查时，很多人看到执行计划里的 rows 很大，就直接开始改索引。更稳妥的判断方式是先看同一个执行迭代器：优化器估算了多少行，实际返回了多少行，以及这个节点被循环了几次。MySQL 的 EXPLAIN ANALYZE 会实际执行语句，并在 TREE 输出中同时展示这些信息。

一、先确认比较对象是同一个迭代器

EXPLAIN ANALYZE 的 TREE 输出不是一张普通结果表，而是由多个迭代器节点组成的计划树。节点旁的 rows 是估算返回行数，actual rows 是执行时观察到的行数，loops 表示该迭代器被重复执行的次数。第一步不要急着算比例，先把这三个值和节点名称对应起来。

例如一段输出可能呈现为下面这样的读法示意，数值只用于说明字段位置：

EXPLAIN ANALYZE
SELECT order_id, total_amount
FROM orders
WHERE customer_id = 42;

-- 关注同一节点括号内的 rows 与 actual rows
-> Index lookup on orders using idx_customer (customer_id=42)
   (cost=..., rows=8)
   (actual time=... rows=37 loops=1)

这里要比较的是同一个 Index lookup 节点里的 8 和 37，而不是拿它和上层 Filter、Join 或下层表扫描的行数比较。对于连接计划，还要把 loops 纳入解释：某个子节点每轮只返回少量行，但被父节点调用很多轮时，累计工作量仍然可能很大。

二、用偏差比值判断估算方向和严重程度

在同一节点上，可以先用一个简单比值做定位：偏差比值 = actual rows / estimated rows。例如估算 10 行、实际 80 行时，比值为 8，属于明显低估；估算 200 行、实际 20 行时，比值为 0.1，属于明显高估。这个公式是阅读计划的计算方式，不是要提交给 MySQL 执行的 SQL。

它不是数据库的硬阈值，而是排查排序。比值接近 1，说明这个节点的估算暂时可用；明显大于 1，说明优化器低估了结果集；明显小于 1，说明优化器高估了结果集。比值越偏，越值得检查它是否改变了索引选择、连接顺序或扫描范围。

三、沿统计信息、谓词和连接边界定位原因

行数偏差通常不是 EXPLAIN ANALYZE 算错，而是优化器只能根据已有统计信息和谓词做估算。应把偏差拆成三层看：真实数据分布是什么，索引基数或直方图向优化器提供了什么，当前 WHERE 条件实际筛出了什么。

如果偏差集中在单列等值条件，先检查该列是否存在严重倾斜：少数值占据了大部分行时，简单的基数估算可能无法代表每个值。若偏差出现在多个条件组合或连接之后，则要进一步观察条件之间是否相关。优化器分别估计各条件并不代表它能准确知道它们的联合分布。

还要区分“估算不准”和“实际计划不理想”。只有当偏差落在影响决策的节点上，例如驱动表选择、连接方式或扫描范围，才值得继续改写 SQL 或索引；一个末端节点略有偏差，不一定就是性能问题。

四、用 ANALYZE TABLE 和对照计划复查

当表中数据经历了大量导入、删除或分布变化，可以在合适的维护窗口更新统计信息，再重新观察计划。MySQL 文档把 ANALYZE TABLE 作为更新键分布信息的手段，但它并不意味着每次都能得到完全精确的全量统计。

-- 在测试环境或明确的维护窗口执行
ANALYZE TABLE orders;

-- 重新观察同一条查询的估算与实际差距
EXPLAIN ANALYZE
SELECT order_id, total_amount
FROM orders
WHERE customer_id = 42;

复查时至少保留三项对照：同一节点的 rows 是否更接近 actual rows，连接顺序或访问方式是否改变，端到端耗时是否真的改善。如果统计信息更新后偏差仍大，不要把它当成“刷新失败”，而应回到谓词相关性、数据倾斜、参数分布和计划稳定性继续定位。

相关问题

rows 越大就一定越慢吗？

不一定。rows 是估算的节点输出规模，实际成本还受访问方式、循环次数、连接关系和每行处理成本影响。

actual rows 很准但查询仍然慢怎么办？

转看 actual time、loops、扫描范围和回表等因素。估算准确只说明数量判断较好，不等于访问路径已经最优。

需要为每个偏差节点都建索引吗？

不需要。先确认偏差是否影响了关键计划选择，再结合写入成本、索引维护成本和其他查询共同评估。

判断 MySQL 行数偏差的核心不是寻找一个神奇阈值，而是把估算 rows、actual rows、loops 放在同一执行节点上阅读，再沿数据分布、统计信息和查询谓词回溯原因。这样得到的修改建议才不会停留在“看到 rows 大就加索引”。