MySQL EXPLAIN FORMAT=JSON 定位回表原因的方法

MySQL 的二级索引命中，并不等于查询已经拿到了最终结果。如果查询还需要索引中没有的列，InnoDB 会先从二级索引找到主键，再根据主键访问聚簇索引记录，这一步就是常说的“回表”。用 EXPLAIN FORMAT=JSON 定位它时，重点不是只看 key 是否非空，而是把 used_key_parts、used_columns、rows_examined_per_scan 和条件字段放在一起判断。

判断回表的实用方法是：先确认实际使用了哪个索引和哪些索引列，再对照查询需要的列。如果返回列或过滤条件依赖索引之外的列，就不能把“使用了索引”当成“没有回表”；如果索引已经覆盖查询所需列，计划中通常会出现覆盖索引相关信号。

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

下面用一个订单表查询说明这套判断方法。示例只解释执行计划字段的阅读方式，不把静态计划当成线上实际耗时证明。

先准备一个可能回表的查询

假设订单表有联合索引 idx_user_status_created，索引顺序是 (user_id, status, created_at)。查询按用户和状态过滤，同时要返回订单金额：

-- 先建立一个只覆盖过滤和排序字段的联合索引
CREATE INDEX idx_user_status_created
ON orders (user_id, status, created_at);

-- amount 不在索引中，命中二级索引后仍可能回表取值
EXPLAIN FORMAT=JSON
SELECT order_id, created_at, amount
FROM orders
WHERE user_id = 1001
  AND status = 'paid'
ORDER BY created_at DESC
LIMIT 20;

这里的 order_id 是主键，通常可以随二级索引记录取得；user_id、status 和 created_at 也在索引中，但 amount 不在其中。即使 key 显示了这个联合索引，存储引擎仍可能为每个候选主键回到聚簇记录读取 amount。

先看 JSON 计划中的索引路径

执行计划的核心对象通常位于 query_block.table。先看下面这些字段，再判断是否需要改索引：

MySQL 官方文档把传统格式中的 key、key_len、rows 等字段映射到 JSON 结构；rows_examined_per_scan 是估算值，不是本次请求已经实际读取的行数。

{
  "query_block": {
    "table": {
      "table_name": "orders",
      "access_type": "ref",
      "key": "idx_user_status_created",
      "used_key_parts": ["user_id", "status"],
      "rows_examined_per_scan": 480,
      "used_columns": ["user_id", "status", "created_at", "order_id", "amount"],
      "attached_condition": "(`orders`.`status` = 'paid')"
    }
  }
}

上面的 JSON 只用于展示阅读方法。看到 key 后还要继续问两个问题：索引中是否包含查询最终要返回的 amount，以及优化器估计需要扫描多少候选记录。

怎样区分覆盖索引和回表

覆盖索引的判断可以用一个简单集合关系表达：查询需要的列集合，必须都能由索引记录直接提供。对 InnoDB 来说，二级索引记录还带有主键值，因此主键列通常可以直接用于结果或继续定位；但普通业务列不在索引中时，仍需要访问聚簇记录。

对本例而言，查询列是 order_id、created_at、amount，过滤列是 user_id、status。当前索引覆盖了过滤和排序字段，却没有覆盖 amount，所以“用了索引”和“完全不回表”是两件事。

如果把索引改成 (user_id, status, created_at, amount)，查询列可能全部由索引提供，计划有机会显示覆盖索引信号。这里的“有机会”很重要：最终仍由优化器结合统计信息、排序方式和查询形状决定，不能只凭索引定义下结论。

-- 仅当该查询是稳定且高频的，才考虑把返回列纳入覆盖索引
CREATE INDEX idx_user_status_created_amount
ON orders (user_id, status, created_at, amount);

-- 重新读取计划，观察 key、used_key_parts 与 used_columns 的组合
EXPLAIN FORMAT=JSON
SELECT order_id, created_at, amount
FROM orders
WHERE user_id = 1001
  AND status = 'paid'
ORDER BY created_at DESC
LIMIT 20;

用扫描行数判断回表代价是否值得优化

回表不是看到就必须消灭的坏事。关键是候选行有多少、查询频率多高，以及增加索引后写入和存储成本是否可接受。rows_examined_per_scan 可以帮助做第一轮排序：同样需要回表时，扫描估算为几十行和几十万行，风险完全不同。

如果扫描估算很大，先检查联合索引的左前缀是否匹配过滤条件，是否把低选择性的列放在了不合适的位置，是否因为函数或隐式类型转换让条件无法有效利用索引。若过滤已经足够精准，再评估把稳定返回列加入索引；不要为了单条低频查询盲目制造宽索引。

还要区分“扫描候选行”和“实际回表行”。JSON 计划给的是优化器估算，数据分布变化、统计信息过期、参数不同，都可能让实际行为偏离。需要时可以先更新统计信息，再用实际执行观测工具或应用侧指标进行独立判断；本文只讨论静态 JSON 计划如何定位方向。

三个容易误判的边界

第一，key 不为空不等于覆盖索引。 它只表示优化器选择了某个索引。仍要对照返回列和过滤列，看是否存在索引缺口。

第二，used_key_parts 不等于完整索引定义。 联合索引可能只用到左侧一部分；剩余列是否能参与过滤、排序或覆盖，需要结合计划中的其它字段和查询条件分析。

第三，rows_examined_per_scan 不是实际耗时。 它是估算行数，适合发现方向和比较候选方案，不适合单独证明某个索引已经带来固定的毫秒收益。

结论与速查

用 EXPLAIN FORMAT=JSON 定位回表，可以按“选了什么索引—实际用了哪些索引列—查询需要哪些列—估算扫描多少行”的顺序阅读。当前索引若不能提供返回列，回表就是正常的执行路径；只有当回表候选量、频率或延迟已经成为问题时，才值得用覆盖索引或更合适的联合索引处理。

常见问题

看到 Using index 就一定没有回表吗？ 这是覆盖索引的积极信号，但仍应结合 JSON 中的列和查询形状理解，不能只看单个字段。

把所有 SELECT 列都加入索引是不是最快？ 不一定。索引变宽会增加存储、写入和维护成本，应先确认查询频率、扫描量和实际收益。

为什么改了索引，JSON 计划还是没变化？ 可能是新索引没有被选择、统计信息尚未反映数据分布，或者查询的瓶颈并不在回表；先比较 key、used_key_parts 与扫描估算，再决定下一步。