命中覆盖索引的明确信号是Extra列显示Using index，且key列对应同一索引；仅key有值而Extra为空或含Using where，说明仍需回表。
执行计划里 key 和 Extra 共同决定是否命中覆盖索引
覆盖索引（Covering Index）不是靠“有没有索引”判断的，而是看查询所需的所有字段是否**全部包含在同一个索引中**，且 MySQL 能仅靠该索引完成查询，无需回表。Navicat 的执行计划里，key 列显示用了哪个索引只是第一步；真正关键的是 Extra 列是否出现 Using index —— 这才是覆盖索引生效的明确信号。
常见误判：看到 key 有值、type 是 ref 或 range，就以为“走索引了”，但若 Extra 是空或含 Using where，说明仍要回主键 B+ 树取其他字段，不算覆盖。
-
Extra = Using index：确认命中覆盖索引，不回表 -
Extra = Using where; Using index：索引覆盖了 WHERE 条件字段，但 SELECT 列还有未被索引覆盖的字段，需回表 -
Extra为空 +key有值：大概率是回表了，只是没显式标注（尤其 MySQL 5.7 及更早版本）
SELECT 字段顺序和索引字段顺序必须对齐
覆盖索引要求 SELECT 的所有列（包括 ORDER BY、GROUP BY 中用到的列）都落在同一索引的字段集合内，且联合索引的字段顺序必须能支撑查询逻辑。不是“字段都在索引里就行”，而是得满足最左前缀+覆盖需求双重条件。
- 建了
INDEX (user_id, status, created_at)，但查询是SELECT status, user_id FROM t WHERE created_at > '2023-01-01'→ 不覆盖：WHERE 条件没用最左字段，且created_at不在索引最左，无法高效定位 - 同样索引，查
SELECT user_id, status FROM t WHERE user_id = 123→ 覆盖：WHERE 用最左，SELECT 字段全在索引中，Extra显示Using index - ORDER BY 字段也必须被覆盖：如
SELECT user_id FROM t ORDER BY status，即使status在索引里，但没作为最左字段，MySQL 无法利用索引排序，会触发Using filesort，同时失去覆盖能力
TEXT/BLOB 字段会让覆盖索引失效
哪怕你在联合索引末尾加了 TEXT 字段（如 INDEX (a, b, content)），MySQL 实际不会把 content 的完整值存进索引页，只存前若干字节（取决于 innodb_large_prefix 和行格式）。所以任何涉及该字段的 SELECT content 或 WHERE content LIKE '%x%' 都无法达成覆盖，Extra 不会出现 Using index。
- 检查表结构：
SHOW CREATE TABLE t看字段类型，遇到TEXT、TINYTEXT、MEDIUMTEXT、BLOB等，直接排除其参与覆盖的可能 - 替代方案：如真需高频查询某类文本特征，可另建生成列（generated column）+ 普通索引，例如
ALTER TABLE t ADD COLUMN content_hash CHAR(32) STORED AS (MD5(content))，再对content_hash建索引 - 注意 VARCHAR(2000) 在某些行格式下也可能被当作“大字段”处理，不建议盲目加长索引长度来覆盖
ANALYZE TABLE 后 rows 值骤降，可能是覆盖索引开始生效
rows 是优化器预估扫描行数，它本身不直接反映是否覆盖，但当你发现 ANALYZE TABLE t 后，同一语句的 rows 从几万掉到几十，且 Extra 新增了 Using index，基本可断定：统计信息更新后，优化器终于意识到“这个索引不仅能定位，还能直接返回结果”，于是切换路径启用覆盖。
- 典型场景：刚批量导入数据后，旧统计让优化器认为“走索引再回表比全表扫还慢”，于是弃用索引；
ANALYZE TABLE后选择性重估，覆盖优势显现 - 别只盯着
rows下降——同步确认key是否还是原索引名、Extra是否新增Using index，三者缺一不可 - 如果
rows没变但Extra出现了Using index，说明优化器成本模型没变，但路径已切到覆盖模式，实际性能仍会提升（省去回表 I/O）
Extra: Using index 这一行输出。很多同学反复调索引字段顺序、加长度、改类型，却漏看这一列——它才是 MySQL 给你的唯一确认回执。 
