覆盖索引是指查询所需所有字段（where、select、order by/group by）均被同一联合索引包含，mysql可直接从二级索引叶子节点获取全部数据，避免回表；判断依据是explain中extra显示using index。
直接用覆盖索引避免回表，核心就一条：让查询涉及的所有字段（WHERE 条件、SELECT 列、ORDER BY/GROUP BY 字段）都落在同一个联合索引里，MySQL 就能只扫一棵索引树，不碰聚簇索引。
怎么看有没有回表？
执行 EXPLAIN 查看执行计划：
- Extra 出现 Using index → 覆盖索引生效，没回表
- 出现 Using where; Using index → 索引下推 + 覆盖，也没回表
- 只有 Using where 或空白 → 没覆盖，必然回表
注意：SELECT * 基本不可能走覆盖索引，因为二级索引不含所有列；哪怕只查三列，也得把它们全建进一个索引里才行。
怎么设计有效的覆盖索引？
按查询实际需要来定制，顺序很关键：
-
等值条件字段放最左（如
user_id = ?） -
范围条件放中间（如
created_at > ?），它右边的字段无法走索引 -
SELECT 和排序字段补在最后（如要查
status, created_at，就加在索引末尾） - 主键 id 自动包含，所以 SELECT id 不额外占空间，但显式写上更清晰
示例：查 SELECT id, status FROM order WHERE user_id = 123 AND created_at > '2025-01-01'，建索引：INDEX idx_user_time_status (user_id, created_at, status)
容易踩的坑
覆盖索引不是写了字段就一定生效，这些情况会悄悄失效：
-
ORDER BY 字段不在索引中，或顺序不匹配 → 即使 SELECT 全覆盖，也可能触发
Using filesort并回表 - TEXT/BLOB 类型字段无法进索引 → 写进联合索引也会被 MySQL 忽略，导致实际未覆盖
- 索引总长度超 3072 字节 → 过长的 VARCHAR 要指定前缀长度，否则建索引失败
- WHERE 含 IS NULL 且列允许 NULL → 优化器可能放弃走索引，务必用 EXPLAIN 验证
特别适合覆盖索引的场景
有些查询天然受益于覆盖索引，效果非常明显：
- COUNT(*) 统计：只要 WHERE 条件能走索引，且不带 SELECT *，就能纯索引扫描
-
深分页（LIMIT 大 offset）：先用覆盖索引查出目标行的 id（如
SELECT id FROM t WHERE ... ORDER BY id LIMIT 1000000, 10），再用这些 id 关联查完整数据，避免上百万次回表 - 只查少量业务字段的列表页：比如用户列表只显示头像 URL、昵称、状态，把这些字段和查询条件一起建索引即可
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
