覆盖索引要求查询所有字段（WHERE、SELECT、ORDER BY等）严格包含在同一二级索引中，否则仍会回表；唯一可靠判断依据是EXPLAIN中Extra显示“Using index”，其余如key非空或type=ref不能证明免回表。
覆盖索引不是“加个索引就完事”，它要求查询涉及的每列（WHERE、SELECT、ORDER BY、GROUP BY）都严格落在同一二级索引的列定义中；否则哪怕只差一个字段，MySQL 仍会执行回表——一次回表 ≈ 一次随机磁盘 IO，1000 行匹配就是上千次额外查找。
怎么一眼看出有没有真正走覆盖索引
别信 key 非空或 type=ref，它们只说明用了索引定位，不保证免回表。唯一可靠信号是 EXPLAIN 输出中 Extra 列是否为 Using index：
-
Using index→ ✅ 真正覆盖，全字段命中索引，不回表 -
Using index condition→ ❌ 用了索引下推（ICP），但 SELECT 字段不在索引里，仍要回表 - 空值、
Using where、Using filesort→ ❌ 没覆盖，甚至可能根本没走索引
示例：EXPLAIN SELECT name, city FROM users WHERE age = 25; 若 Extra 是 Using index，说明存在类似 idx_age_name_city(age, name, city) 的联合索引；若仍是空，则索引缺字段或顺序不对。
建覆盖索引时最常踩的三个字段陷阱
覆盖索引失效往往不是因为没建，而是字段选错、顺序写反、类型隐式转换：
-
TEXT/BLOB字段不能直接进索引，建INDEX(a, content)会失败或被截断；必须用前缀索引，如content(100) -
SELECT *永远无法被覆盖（除非用主键索引本身），因为二级索引叶子节点只存主键+索引列，不存整行 - 字段顺序违反最左前缀：索引
(status, name, email)可覆盖WHERE status = ? AND name = ?+SELECT email，但无法用于WHERE name = ?或仅SELECT email
额外注意：如果 ORDER BY created_at 出现在查询中，但 created_at 不在索引列里，即使其他字段都覆盖了，MySQL 也可能放弃该索引，改走 Using filesort 并回表。
为什么加了字段还是没触发 Using index
表面看索引字段齐全，但优化器实际弃用了它，常见原因有：
- 隐式类型转换：比如
WHERE phone = 13800138000（数字）查VARCHAR字段，或 collation 不一致，导致索引失效 - 函数包裹字段：
SELECT UPPER(name) FROM t WHERE name = 'alice'，即使name在索引里，UPPER()也会阻止覆盖（MySQL 8.0+ 支持函数索引，但需显式创建INDEX((UPPER(name)))） - 高更新频率字段入索引：如把
updated_at加进覆盖索引，每次 UPDATE 都要更新索引页，写放大严重，优化器可能权衡后主动降级使用
验证方式很简单：删掉函数、统一类型、固定 WHERE 条件写法后重跑 EXPLAIN，看 Extra 是否变成 Using index。
覆盖索引真正的难点是“对齐”，不是“堆砌”
你设计的索引字段、顺序、长度，必须和真实查询的 WHERE 条件顺序、SELECT 显式列表、ORDER BY 依赖完全咬合。漏掉一个 IS NULL 判断、多一个 COLLATE utf8mb4_0900_as_cs、或者 GROUP BY 里用了别名而索引没包含该表达式列——都会让优化器绕开你精心建的覆盖索引。
线上慢查询里，Extra 显示 Using index 却依然慢？先检查是否真在走这个索引（看 key 字段）、再确认查询语句是否和建索引时设想的 SQL 完全一致。覆盖索引不是配置项，它是查询与索引之间的一份精确契约。
