MySQL EXPLAIN 里 rows 很小但查询仍慢：回表次数与覆盖索引验收

线上订单列表明明只命中几百行，接口却比预期慢很多，最容易被忽略的地方是：EXPLAIN 里的 rows 只是优化器估算要读多少条索引记录，不是完整 SQL 的总成本。二级索引命中后，如果还要回到聚簇索引取出多个列，磁盘页访问和随机读取可能把这点“几百行”放大。

不少开发同学写完SQL用EXPLAIN一看，估算扫描行数rows才几十，觉得性能肯定没问题，结果实际跑起来响应还是很慢，排查半天找不到根因。这类问题基本都出在容易被忽略的回表额外开销上，我们一步步拆解排查思路和验证方法。

先看执行计划是否发生回表，再用覆盖索引实验验证收益；不要只因为 rows 数字小，就认定查询已经足够快。

先把 rows 和真实读取分开看

假设订单表按租户和状态筛选，页面只显示最近一页订单：

SELECT id, user_id, amount, created_at
FROM orders
WHERE tenant_id = 17 AND status = 'paid'
ORDER BY created_at DESC
LIMIT 50;

如果索引是 (tenant_id, status, created_at)，优化器可能估算 rows=320。这表示它预计扫描约 320 条索引记录，但索引里没有 user_id 和 amount，每一条候选记录还要拿主键回到聚簇索引取完整行。数据页分散、缓存不热或返回列较多时，耗时就不再和 320 这个数字成正比。

用同一组参数建立性能基线

不要先改索引再看结果。先把条件、排序、返回列和数据分布固定下来，连续执行几次，避开第一次加载缓存造成的误判。测试时保留完整计划：

EXPLAIN FORMAT=JSON
SELECT id, user_id, amount, created_at
FROM orders
WHERE tenant_id = 17 AND status = 'paid'
ORDER BY created_at DESC
LIMIT 50;

重点记录 key、rows_examined_per_scan、是否出现回表相关的额外读取，以及实际耗时。MySQL 8.0 还可以用：

EXPLAIN ANALYZE
SELECT id, user_id, amount, created_at
FROM orders
WHERE tenant_id = 17 AND status = 'paid'
ORDER BY created_at DESC
LIMIT 50;

EXPLAIN ANALYZE 会实际执行语句，结果中的实际行数和耗时比单看估算值更适合验收。生产环境不要直接对会修改数据的语句这样试，查询也要控制返回规模。

覆盖索引实验只增加真正需要的列

如果页面始终只需要这四个字段，可以把查询列补进索引，形成覆盖路径：

ALTER TABLE orders
  ADD INDEX idx_orders_list_cover
  (tenant_id, status, created_at, id, user_id, amount);

再次执行同一条查询，比较执行计划和耗时。覆盖索引的价值不是让 rows 必然变小，而是让引擎可以直接从索引叶子节点拿到返回列，减少回到聚簇索引的次数。要注意排序方向、最左匹配和 LIMIT 共同决定它是否真的有效；索引存在并不等于查询一定使用它。

验收时看三组结果，不只盯一个数字

执行计划是否稳定

对比两次 EXPLAIN 的 key、扫描行数、排序方式和实际执行时间。数据量或统计信息变化后，优化器可能重新选择索引，所以要在接近线上数据分布的副本上复测。

读取动作是否减少

可以在测试连接里观察执行前后的 Handler 计数，重点看随机读取和读取下一条记录的变化趋势。计数不是跨环境的绝对分数，但能帮助判断“只是计划变了”还是“实际访问动作少了”。

写入和空间代价是否可接受

覆盖索引会增加索引体积，也会让插入、更新和页分裂承担更多成本。若 amount 经常变更，或同一张表有大量类似列表查询，把所有返回列都塞进索引未必划算。先确认热点查询，再决定是否保留。

几个看似有效的改法为什么会失效

第一，盲目把 rows 当成真实读取行数，容易错过回表。第二，只新增一个单列索引，可能既无法覆盖返回列，也无法满足组合条件和排序。第三，用空表或缓存极热的数据测试，会把索引收益夸大。第四，查询已经只返回 50 行，却为了“更快”建立一条包含十几个大字段的宽索引，最后写入成本超过了读取收益。

这里更稳妥的做法是保留一份基线 SQL、计划 JSON、样本数据规模和多次耗时，再用同一批条件做前后对比。没有可复现的基线，索引优化很容易变成凭感觉调参。

常见问题与延伸判断

rows 很小是不是就不用优化？

不是。rows 是估算扫描量，仍需结合实际耗时、返回列、回表和排序判断。

覆盖索引一定比普通索引快吗？

不一定。它可能减少回表，但会扩大索引并增加写入维护成本；只有在热点读查询中复测有效，才值得保留。

为什么加了覆盖索引却没有被使用？

可能是选择性不足、统计信息不准、排序条件不匹配，或优化器判断回表成本仍更低。用实际数据运行 EXPLAIN ANALYZE，不要只看索引定义。

小结

排查“rows 很小但查询仍慢”时，先把估算扫描量和真实数据页访问拆开，再用普通索引与覆盖索引的同条件实验验证。最终决策同时考虑读性能、索引空间和写入维护，不要把一个漂亮的 rows 数字当成完整结论。