覆盖索引是否生效的唯一依据是explain中extra列严格等于using index；using index condition仅表示索引下推仍需回表，using where或空值则必然回表。
EXPLAIN 的 Extra 列必须是 Using index
覆盖索引是否生效，唯一可信依据就是 EXPLAIN 输出中 Extra 字段的值。只有当它**严格等于** Using index 时，才表示 MySQL 完全从二级索引叶子节点取到了全部所需数据，没回表。
常见混淆点：
-
Using index condition：只是启用了索引下推（ICP），WHERE 中部分条件在引擎层过滤，但之后仍要回表查其他字段 -
Using where或空值：说明走了索引做查找，但 SELECT 的字段不全在索引里，必然回表 -
Using filesort或Using temporary：和覆盖无关，但往往意味着索引设计没兼顾 ORDER BY / GROUP BY，间接导致无法稳定触发覆盖
SELECT 字段、WHERE 条件、ORDER BY/GROUP BY 必须全部落在同一索引列中
不是“WHERE 用了索引”就叫覆盖，而是整条查询涉及的所有列（包括隐式需要的）都得被同一个二级索引“包圆”。
实操检查清单：
- 执行
SHOW INDEX FROM table_name或查INFORMATION_SCHEMA.STATISTICS，确认该索引包含哪些列、顺序如何 - 核对
SELECT列表：不能有*，也不能出现索引未包含的字段（比如索引是(status, city)，却SELECT status, city, email） - 核对
WHERE条件：必须能走该索引，且最左前缀匹配（WHERE city = ?对(status, city)索引无效） - 核对
ORDER BY或GROUP BY：如果存在，字段也得在索引里，且顺序需支持跳过文件排序（例如索引(a, b, c)，ORDER BY a, b可免排序，ORDER BY b, c就不行）
这些写法会让覆盖索引“静默失效”
建了索引、EXPLAIN 显示用了 key，但 Extra 不是 Using index？大概率掉进了以下陷阱：
- 对索引字段用了函数：
WHERE YEAR(created_at) = 2025→ 改成WHERE created_at >= '2025-01-01' AND created_at - 发生隐式类型转换：
WHERE mobile = 13812345678（mobile 是VARCHAR）→ 改成WHERE mobile = '13812345678' - 用了
TEXT/BLOB字段：这类字段无法被完整存入二级索引叶子节点，只要 SELECT 或 WHERE 涉及它们，覆盖即失效 - 索引列顺序错位：比如想覆盖
SELECT name, email FROM t WHERE city = 'sh'，却建了INDEX(name, email, city)——city不是最左，索引根本用不上
InnoDB 中主键 ID 是“免费赠送”的，不用显式加进索引
InnoDB 的二级索引叶子节点默认存储索引列值 + 主键 ID。所以 SELECT id, name 比 SELECT name 更容易命中覆盖索引，哪怕索引定义里没写 id。
这意味着：
- 联合索引
(status, name)能覆盖SELECT id, status, name，但不能覆盖SELECT id, status, name, email（email 不在索引中） - 如果你常查
id+ 若干字段，优先把高频字段放索引后缀，别浪费空间重复加id - 注意：这个“隐含 id”只对 InnoDB 有效，MyISAM 不适用
真正难的不是建索引，是让每一条查询都稳稳落在 Using index 上——它要求你同时盯住 SQL 写法、索引结构、字段类型、甚至字符集排序规则。稍有偏差，优化器就悄悄切回回表路径。
