MySQL 覆盖索引实战：少一次回表，查询为什么会更快

MySQL 索引优化里，经常能听到“覆盖索引”这个词。它听起来像一个新索引类型，其实不是。覆盖索引指的是：查询需要的字段，都能从某个索引里直接拿到，不需要再回到主键索引或数据行里取完整记录。

很多列表接口慢，不是因为没有索引，而是索引用了一半：条件能走索引，但返回字段还要回表。本文用后台订单列表查询做例子，讲清楚普通索引、回表、覆盖索引和 EXPLAIN 验证。

摘要

覆盖索引的关键不是“索引越多越好”，而是让查询条件、排序字段和返回字段尽量落在同一个联合索引里。这样 MySQL 可以直接从索引页返回结果，减少随机读和回表次数。判断是否覆盖，重点看 EXPLAIN 的 Extra 是否出现 Using index。

适合人群

适合已经会写基本 SQL、知道普通索引和联合索引，但对“回表”和“覆盖索引”还不够有把握的后端开发者、DBA 入门同学。

目录

• 先准备一个订单列表场景
• 普通索引为什么还会回表
• 怎么设计覆盖索引
• 用 EXPLAIN 判断是否覆盖
• 常见坑和上线检查

一、先准备一个订单列表场景

假设后台有一个订单列表，只展示用户最近的订单号、状态、金额和创建时间。表结构简化如下：

CREATE TABLE orders (
  id BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
  user_id BIGINT UNSIGNED NOT NULL,
  order_no VARCHAR(32) NOT NULL,
  status TINYINT NOT NULL,
  amount DECIMAL(10, 2) NOT NULL,
  remark VARCHAR(255) NOT NULL DEFAULT '',
  created_at DATETIME NOT NULL,
  KEY idx_user_created (user_id, created_at)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

查询语句如下：

SELECT order_no, status, amount, created_at
FROM orders
WHERE user_id = 10001
ORDER BY created_at DESC
LIMIT 20;

这个查询能走 idx_user_created，但它仍然可能需要回表。因为索引里只有 user_id、created_at 和主键值，返回字段里的 order_no、status、amount 不在这个索引里。

二、普通索引为什么还会回表

InnoDB 的二级索引叶子节点通常保存索引列和主键值。当查询需要的字段不在二级索引里，MySQL 会先通过二级索引找到主键，再回到主键索引里取完整行，这一步就叫回表。

图里的红色路径表示普通索引：索引能定位记录，但字段不够，只能拿主键再回表。绿色路径表示覆盖索引：索引已经包含查询要返回的字段，MySQL 可以直接从索引里把结果取出来。

对于只查 20 条的小列表，回表不一定明显；但如果列表接口访问频繁，或者筛选条件命中大量记录，回表带来的随机读就会逐渐放大。

三、怎么设计覆盖索引

覆盖索引要围绕真实查询设计。这个订单查询包含三类字段：

• 过滤字段：user_id
• 排序字段：created_at
• 返回字段：order_no、status、amount、created_at

可以把索引调整成：

ALTER TABLE orders
  ADD KEY idx_user_created_cover (
    user_id,
    created_at,
    order_no,
    status,
    amount
  );

这样查询所需字段都在索引中，MySQL 有机会直接从索引返回结果：

SELECT order_no, status, amount, created_at
FROM orders
WHERE user_id = 10001
ORDER BY created_at DESC
LIMIT 20;

注意，覆盖索引不是让你把所有字段都塞进索引。比如 remark 是较长字段，列表页也不展示，就不应该为了“万一要用”放进去。索引越宽，写入成本和存储成本越高。

四、用 EXPLAIN 判断是否覆盖

优化后不要靠感觉，要用 EXPLAIN 看查询计划。

EXPLAIN
SELECT order_no, status, amount, created_at
FROM orders
WHERE user_id = 10001
ORDER BY created_at DESC
LIMIT 20;

重点看几个字段：

• key：实际使用的索引是否是新建的覆盖索引。
• rows：预估扫描行数是否合理。
• Extra：如果出现 Using index，通常说明查询能从索引中取到需要的列。

上图的流程很实用：先跑 EXPLAIN，再看 Extra 是否出现 Using index；如果没有，就检查返回字段是否超出了索引范围，再调整联合索引并重新验证。

一个常见对比

-- 可能覆盖
SELECT order_no, status, amount, created_at
FROM orders
WHERE user_id = 10001
ORDER BY created_at DESC
LIMIT 20;

-- 加了 remark 后可能不再覆盖
SELECT order_no, status, amount, created_at, remark
FROM orders
WHERE user_id = 10001
ORDER BY created_at DESC
LIMIT 20;

第二条 SQL 多查了 remark。如果覆盖索引里没有这个字段，MySQL 就需要回表。列表接口里“顺手多查一个字段”，经常就是覆盖索引失效的原因。

五、什么时候不适合做覆盖索引

覆盖索引很好用，但不是每个查询都要覆盖。下面几种情况要谨慎：

• 返回字段很多，索引会变得很宽。
• 字段很长，例如大文本、备注、JSON 字段。
• 表写入非常频繁，额外索引会增加写入成本。
• 查询本身频率很低，优化收益不明显。

更稳的做法是先从高频列表、接口慢查询、后台常用筛选页开始改。覆盖索引最好服务于具体 SQL，而不是抽象地“给表加一个万能索引”。

常见问题

1. Using index 一定代表最快吗？

不一定。它说明查询可能只读索引，但如果索引选择性差、扫描行数很大，仍然会慢。要结合 rows、实际耗时和业务数据分布一起看。

2. 覆盖索引和联合索引是什么关系？

覆盖索引是一种查询效果，联合索引是一种索引结构。很多覆盖索引通过联合索引实现，但不是说所有联合索引都能覆盖查询。

3. select * 能用覆盖索引吗？

一般很难。select * 要求返回所有字段，普通联合索引通常不可能包含整行数据。线上接口建议只查真正需要展示的字段。

上线前检查清单

• SQL 是否只查询页面真正需要的字段。
• 联合索引是否包含过滤字段、排序字段和必要返回字段。
• EXPLAIN 的 key 是否命中新索引。
• Extra 是否出现 Using index。
• 新增索引是否会给写入、磁盘空间和维护成本带来明显压力。

总结

覆盖索引的价值在于减少回表。它不神秘，也不是简单堆索引，而是让高频查询需要的字段尽量在同一个索引里被满足。实战时先从具体慢 SQL 入手，设计联合索引，再用 EXPLAIN 验证 Using index 和扫描行数。能少一次回表，很多列表查询就会轻不少。