覆盖索引生效的唯一判断依据是：key列非空且extra为using index；using index condition仅为索引下推，不表示覆盖，二者不可混淆。
EXPLAIN里key和Extra同时满足什么条件才算覆盖索引
覆盖索引生效的唯一判断依据是：key列非空（说明走了某个索引），且Extra字段包含Using index——注意不是Using index condition，后者是索引下推，两者完全无关。
常见误判点：
-
key为空但Extra有Using index？不可能，MySQL不会在没走索引的情况下显示这个标记 -
type是index（全索引扫描）且Extra含Using index？算，只要没回表，仍是覆盖索引 - 联合索引
idx_a_b_c(a,b,c)，查询SELECT a,b FROM t WHERE a=1→ 满足；但SELECT a,c→ 不满足，因为c不连续，需回表查主键
为什么看到Using index却查询仍慢
覆盖索引只解决“是否回表”，不解决“扫描多少行”。如果rows值极大，哪怕不回表，I/O 和 CPU 开销依然高。
典型场景：
- 索引选择性差：比如
status只有 3 个取值，WHERE status = 'pending'扫了 80% 行数，Extra虽是Using index，但效率低 - ORDER BY 无法利用索引排序：即使
SELECT字段全在索引里，若ORDER BY b而索引是(a,b)且a是范围条件，则仍会触发Using filesort - 大字段被包含在索引中：
TEXT或长VARCHAR列建在联合索引里，会导致索引页膨胀，实际读取成本上升
Navicat里怎么快速验证覆盖索引是否真被用上
别只看单条语句，要对比关键字段变化：
- 执行
EXPLAIN SELECT a,b FROM users WHERE a = 1，确认key为idx_a_b、Extra含Using index - 再执行
EXPLAIN SELECT a,b,c FROM users WHERE a = 1（假设c不在索引中），此时Extra变成Using where; Using index或干脆消失，key可能不变但已失去覆盖能力 - 如果表有主键自增
id，而你查SELECT id,a,b，即使id不在联合索引里，InnoDB 也会隐式带上主键，此时Extra仍可能是Using index——这是特例，不代表id被索引覆盖，只是B+树叶子节点天然存主键
容易被忽略的覆盖索引失效点
这些写法会让Extra丢掉Using index，哪怕字段全在索引里：
- 对索引字段用函数：
SELECT a,b FROM t WHERE UPPER(a) = 'X'→ 索引失效，更别说覆盖 - 隐式类型转换：
WHERE a = 123但a是VARCHAR→ 转换后无法走索引 - SELECT 中含
*：即使所有列都在索引中，*仍可能触发优化器绕过覆盖逻辑（尤其在旧版本 MySQL 中） - 使用
DISTINCT或GROUP BY时字段顺序不匹配索引最左前缀，可能导致额外排序或临时表
覆盖索引不是“建了就完事”，它高度依赖查询写法与字段顺序的严丝合缝。哪怕多一个逗号、少一个等号，Using index就可能消失。
