MySQL EXPLAIN 看行数偏差 怎样处理

MySQL EXPLAIN 里的 rows 是优化器对某个迭代器将返回多少行的估算，不等于查询最终返回的真实行数。遇到偏差时，先用 EXPLAIN ANALYZE 对照估算值和实际值，再判断是统计信息过期、列分布倾斜，还是谓词本身让估算难以成立。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/

最稳妥的处理顺序是：定位偏差最大的迭代器，采集实际行数，刷新统计信息后复测；只有确认数据分布仍然无法表达时，才考虑为列建立直方图或调整查询和索引。

先把 rows 偏差看成估算问题

传统格式的 rows 反映优化器预计从当前表或索引访问路径取得的行数，filtered 则表示经过当前条件后预计保留的百分比。两者不能简单相加，也不能拿单个节点的 rows 和最终结果集直接比较：连接顺序、循环次数和上游输入都会改变含义。

例如一个按状态和时间过滤的订单查询，状态值可能高度倾斜。优化器若只掌握粗略索引基数，就可能把“少量待支付订单”估成大量行，进而选择不合适的连接顺序。这个现象首先说明估算输入需要核对，不自动说明“必须加索引”。

用 EXPLAIN ANALYZE 建立前后对照

在可接受查询实际执行的测试或低风险环境中，先保存普通计划，再运行：

-- 让优化器估算和迭代器实际行为同时出现
EXPLAIN ANALYZE
SELECT order_id, created_at
FROM orders
WHERE status = '待支付'
  AND created_at >= '2026-01-01';

MySQL 8.4 的结果使用 TREE 形式，通常能看到估算 rows、actual time、rows 和 loops。重点不是寻找一个“误差倍数阈值”，而是找出哪个节点在多次循环中持续偏离，并确认偏差是否真的带来了更高耗时。

如果不能在生产直接执行，先把同样的数据分布复制到隔离环境；不要把 EXPLAIN ANALYZE 当成只读计划查看命令，因为它会执行语句。读写语句尤其要使用经过确认的测试副本。

统计信息不准时先修正输入

对 InnoDB，索引基数和数据分布统计本身就是估算。数据批量导入、删除或分布明显变化后，可以先更新表统计：

-- 只刷新优化器依赖的表与索引统计，不改变查询文本
ANALYZE TABLE orders;

执行前确认权限、锁影响和复制策略；完成后重新执行同一条 EXPLAIN 与 EXPLAIN ANALYZE，比较访问类型、连接顺序、估算 rows、actual rows 和耗时。若计划发生变化但实际没有改善，说明统计修正不是最终答案，不应为了让 rows 看起来接近而保留变更。

如果问题集中在一个非均匀分布的过滤列，可以进一步建立直方图：

-- 为倾斜分布的过滤列补充桶统计；桶数按数据规模和复测结果调整
ANALYZE TABLE orders
  UPDATE HISTOGRAM ON status WITH 32 BUCKETS;

-- 需要撤销时删除该列直方图
ANALYZE TABLE orders DROP HISTOGRAM ON status;

直方图是补充信息，不是索引替代品；采样、列类型、唯一索引限制和版本能力都要结合手册确认。对范围条件还要检查边界是否使用了正确的数据类型和时区表达式。

把索引与查询边界放到最后判断

统计信息更新后仍然偏差很大，再检查联合索引的列顺序、隐式类型转换、函数包裹列、相关子查询以及连接条件是否改变了选择性。不要只盯着最终结果行数：如果某个节点估算 100 行、实际 1000 行，但只循环一次且耗时很小，优先级可能低于一个估算 1000 行、实际 10 万行并循环多次的节点。

建议保留一张变更对照表：

常见疑问

EXPLAIN 的 rows 和 COUNT(*) 为什么不一样？

前者是计划阶段的估算，后者是执行后的统计或结果；数据分布、统计信息和查询条件都会造成差异，不能用一次差异直接判定计划错误。

刷新 ANALYZE TABLE 后仍然偏差怎么办？

继续用 EXPLAIN ANALYZE 找偏差最大的节点，检查数据倾斜、谓词边界、类型转换和联合索引顺序；直方图或查询改写都应以实际耗时改善为验收条件。

小结：先区分估算与实际，再刷新统计信息，最后才调整索引和查询。这样处理 MySQL EXPLAIN 的行数偏差，目标是让执行路径更适合真实数据，而不是机械追求两个数字完全相等。