索引覆盖指查询仅通过索引B+树叶子节点获取全部数据，无需回表；EXPLAIN中出现Using index即表示成功覆盖。
判断一个SQL查询是否能走索引覆盖，核心看SELECT字段和WHERE条件字段是否全部被同一个索引包含，且该索引的列顺序满足最左前缀原则；一旦需要回表，说明索引中缺失了查询所需的部分列（尤其是SELECT中的非索引列或ORDER BY/GROUP BY中未被覆盖的列）。
什么是索引覆盖？
当一条查询语句执行时，仅通过B+树的叶子节点就能获取所有需要的数据，无需回主键索引（聚簇索引）查找整行记录，就称为“索引覆盖”。此时执行计划中会出现 Using index 标识。
- 例如：表 user(id PK, name, age, city)，建立联合索引 (city, age, name)；
- 执行
SELECT name, age FROM user WHERE city = 'Beijing'→ 可索引覆盖； - 但
SELECT name, age, id FROM user WHERE city = 'Beijing'→ 不一定覆盖（id 是主键，InnoDB 中二级索引叶子节点存的是主键值，所以仍可能免回表；但若查的是email这类非索引列，必然回表）。
什么情况下一定会触发回表？
只要查询中出现任何未被当前使用索引包含的列（包括 SELECT、ORDER BY、GROUP BY、HAVING 中引用的列），且该列不属于该索引定义的一部分，就会触发回表。
- SELECT * 几乎总是回表（除非是唯一索引且表只有几列，还极少见）；
- WHERE 条件用了索引，但 SELECT 中有额外列：如索引是 (a,b)，却查
SELECT a,b,c→ c 导致回表； - ORDER BY 字段不在索引中，或顺序/方向不匹配：如索引 (a,b ASC)，却
ORDER BY a, b DESC→ 可能无法利用索引排序，优化器可能放弃覆盖而选择回表+文件排序； - 使用了函数或表达式：如
WHERE YEAR(create_time) = 2023，即使 create_time 有索引，也无法用上索引覆盖（索引失效+需计算后比对）。
如何验证是否发生索引覆盖？
直接看 EXPLAIN 结果中的 Extra 列：
- 出现 Using index → 索引覆盖成功；
- 出现 Using where; Using index → 也是覆盖（WHERE 在索引上完成过滤，结果直接从叶子节点读出）；
- 出现 Using where; Using index condition → 是ICP（索引下推），部分过滤在存储引擎层做，但仍属覆盖范畴；
- 只写 Using where 或 Using filesort / Using temporary → 大概率未覆盖，已回表。
避免回表的实用建议
不是索引越多越好，而是要让高频查询的“查询列 + 过滤列 + 排序列”尽量落在同一索引中：
- 把 WHERE 等值条件列放最左，范围查询列（如 >, LIKE 'abc%'）靠右，SELECT 和 ORDER BY 列追加在最后；
- 避免在索引列上使用函数、类型隐式转换、NOT、!=、IS NULL 等易导致索引失效的操作；
- 对宽表（列多）且 QPS 高的查询，可考虑单独建覆盖索引，哪怕冗余，也比回表带来的随机IO更高效；
- 注意索引长度：过长的 VARCHAR 或 TEXT 建索引会拖慢性能，必要时用前缀索引 + 覆盖权衡。
