当前位置：首页 > 文章列表 > 数据库 > MySQL > MySQL 覆盖索引实战：少一次回表，查询为什么会更快

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

来源：17golang原创 2026-06-13 08:57:26 0浏览收藏

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

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

摘要

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

适合人群

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

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

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

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 普通索引缺少字段需要回表覆盖索引包含字段后可直接返回结果

图里的红色路径表示普通索引：索引能定位记录，但字段不够，只能拿主键再回表。绿色路径表示覆盖索引：索引已经包含查询要返回的字段，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，通常说明查询能从索引中取到需要的列。

MySQL 通过 EXPLAIN 查看 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 就需要回表。列表接口里“顺手多查一个字段”，经常就是覆盖索引失效的原因。