MySQL EXPLAIN ANALYZE 怎么核对估算与实测：耗时分布、行数偏差与慢查询定位

线上订单列表查询延迟突然从120毫秒飙升到2秒的时候，别上来就忙着给SQL堆索引。很多时候问题根源都藏在优化器的估算结果和实际执行的偏差里：优化器预估只需要扫40行，实际执行直接跑了180万行，还有的单个执行节点耗时看着不高，但重复循环的次数直接把总耗时放大了几十上百倍。

MySQL 8.4 的 EXPLAIN ANALYZE 适合回答“计划为什么这样选、实际跑成了什么样”。重点看每个迭代器的 cost、估算 rows、actual time、实际行数和 loops，不要只盯着最外层总耗时。

为什么只看 EXPLAIN 还不够

常规 EXPLAIN 展示的是优化器对执行路径的判断，例如访问类型、可能使用的索引、估算行数和过滤比例。这些数字是计划阶段的预测，不等于查询真正跑过后的结果。

当订单表最近从几百万行增长到几千万行，或者某个状态字段的分布从原来的均匀分布，变成绝大多数值都是paid的倾斜状态，优化器的预估就可能明显偏离实际。此时哪怕SQL本身没有做任何修改，执行计划也可能从高效的范围扫描，变成需要大量回表的嵌套循环，直接拖慢整体速度。

EXPLAIN
SELECT order_id, user_id, created_at
FROM orders
WHERE status = 'paid'
  AND created_at >= '2026-08-01'
ORDER BY created_at DESC
LIMIT 50;

EXPLAIN ANALYZE 会真正执行语句，并在 TREE 输出中补充每个迭代器的估算成本、估算返回行数、首行时间、迭代器耗时、实际返回行数和循环次数。官方示例中的 actual time 单位是毫秒。

先把估算 rows 和 actual rows 对齐

我排查的时候习惯从最底层的叶子节点往上捋，不会一上来就从执行计划第一行从头扫。叶子节点能直接告诉你数据是从哪张表、哪个索引取的；上层的Filter过滤、Sort排序或是Join连接节点，能看到这些数据后续经过了哪些处理。顺着找到第一个估算和实际出现明显偏差的节点，定位问题的速度会快很多。

例如某个索引范围节点显示 rows=40，但 actual ... rows=1800000 loops=1，问题首先不是“数据库慢”，而是估算错得太远。若子查询节点显示 actual rows=1 loops=50000，则要把单次耗时乘上循环次数，才能判断它对总耗时的贡献。

三类偏差分别怎么查

估算行数偏小：先看分布和统计信息

状态、租户、地区这类列经常有明显倾斜。先用业务允许的方式检查实际分布，再确认统计信息是否在数据大幅变化后更新。MySQL 的 ANALYZE TABLE 可以生成表统计信息，但更新统计信息不是无条件的线上动作，仍需安排在可控窗口并观察计划是否改变。

ANALYZE TABLE orders;
EXPLAIN ANALYZE
SELECT order_id
FROM orders
WHERE tenant_id = 42 AND status = 'paid';

刷新统计信息之后如果估算结果和实际执行行数的偏差明显缩小，那根因大概率就是统计信息过期；要是更新完统计信息偏差还是很大，那就回头排查谓词组合逻辑、数据分布倾斜情况和索引前缀的合理性。

loops 很高：检查驱动表和关联条件

嵌套循环连接本身不是天生的性能问题，小结果集当驱动表、内表又有适配的索引的时候，它的执行速度反而很快。真正有风险的情况是外层实际返回的行数远超过优化器的预估值，导致内层的索引查找逻辑被重复执行几十万次，直接把总耗时拉满。

这时把 Join 两侧的实际行数、循环次数和连接列一起看。不要单独把某个 loops 高的节点判为问题，先确认它是不是被一个错误的上游估算放大。

耗时集中在排序或过滤：确认是否把大量数据带到上层

如果最底层的扫描节点已经返回了大量数据，后面的Filter过滤或是Sort排序节点才出现高耗时，这时候直接新建索引未必是第一选择。先确认过滤条件的选择性高低和排序需求，再对比覆盖索引、缩减返回字段数量或是调整查询边界的改造成本，选性价比最高的方案。

一次可复现的核对流程

1. 保留原始 SQL、参数和数据范围，先执行普通 EXPLAIN 记录计划。
2. 在可控环境执行 EXPLAIN ANALYZE，保存完整 TREE 输出，不要只抄最外层一行。
3. 从叶子节点向上找估算与实际的第一个大偏差，标记对应表、索引、谓词或Join。
4. 只改一个变量，例如刷新统计信息或调整索引，再用相同参数重新采集。
5. 用业务关注的p95、返回行数和锁等待做最终验收，避免把单次实验耗时当成上线结论。

需要注意的是，EXPLAIN ANALYZE 会执行语句。查询类语句也可能触发真实的资源消耗；涉及多表 UPDATE 或 DELETE 时，更要在副本或经过授权的验证环境中操作，确认语句边界和回滚方案。

几个容易把结论带偏的边界

第一，冷缓存与热缓存的结果不能直接比较。第二，测试数据量太小，会让索引和 Join 的代价看起来过于理想。第三，单次 EXPLAIN ANALYZE 只能描述这一次参数和当时的数据状态，不能替代稳定的压测或线上指标。

另外，actual time 是迭代器层的时间信息，不能简单地把每个节点的时间相加当成端到端耗时，因为父子节点存在包含关系。对比时保持采集方式一致，比追求某一个数字更重要。

延伸问答

EXPLAIN ANALYZE 会不会修改 SELECT 查询的数据？

SELECT 本身不修改业务数据，但它会真实消耗 CPU、内存、I/O 和锁相关资源。生产环境应先限制范围，并评估并发影响。

为什么 actual rows 比 rows 大很多？

常见原因包括统计信息过旧、列值分布倾斜、谓词相关性未被准确表达，以及参数对应的数据范围与平时不同。

看到 loops 很高是否一定要换索引？

不一定。先确认高循环是由哪个上游节点的实际行数触发，再比较驱动表选择、连接条件和索引可选性，避免对着表面症状乱加索引。

把一次执行树变成回归证据

成熟的执行计划排查不是只截图留档，而是让同一条SQL在同一组参数下能够解释清楚“改动前后执行计划为什么不同”。把估算行数、实际行数、循环次数和关键节点耗时一起记录，后续再遇到慢查询时，才有办法快速区分是数据变化导致的问题、统计信息出问题，还是执行计划本身出现了回归。