覆盖索引是指索引包含查询所需全部字段，使mysql无需回表即可返回结果；explain中extra显示“using index”即表示生效，且需确保select列、where条件列等均被索引覆盖。
覆盖索引不是“加个索引就快”，而是让 MySQL 在一次索引扫描中拿到全部要返回的字段，彻底跳过回表——只要 EXPLAIN 的 Extra 字段出现 Using index，你就成功了。
怎么确认你的查询真的用了覆盖索引
别猜，直接 EXPLAIN 看 Extra 列：
-
Using index✅ 表示真正覆盖：WHERE 条件和 SELECT 字段全在索引里，只扫一棵索引树 -
Using where; Using index✅ 也是覆盖，且 WHERE 过滤已在索引层完成（ICP 生效） -
Using index condition❌ 不算覆盖，只是用了索引下推，仍要回表取非索引列 -
Using where或空值 ❌ 必然回表，哪怕只差一个字段没进索引 -
SELECT *几乎永远触发不了Using index，因为二级索引不存所有列
联合索引字段顺序怎么排才有效
顺序错，等于白建。核心是按查询执行路径组织：
- 最左放 WHERE 中的等值条件列（如
user_id = ?），必须满足最左前缀匹配 - 中间放范围条件列（如
created_at > ?），它右边的字段无法用于索引查找 - 最后补 SELECT 中需要的非条件字段（如
status,nickname），它们不参与查找，但必须存在才能覆盖 - 主键
id自动包含在二级索引中，显式写上更清晰，也不额外占空间 - 避免把低区分度列（如
is_deleted）放最左，优化器可能直接弃用该索引
哪些情况看似覆盖、实则失效
几个高频翻车点：
-
TEXT或BLOB类型字段无法被索引存储，哪怕你写进联合索引，MySQL 也会静默忽略，导致实际未覆盖 - 索引总长度超 3072 字节（InnoDB 默认），建索引会失败；长
VARCHAR必须指定前缀，如VARCHAR(255)改为VARCHAR(191) -
ORDER BY字段不在索引中，或顺序不匹配（比如索引是(a, b)却ORDER BY b, a），即使字段全覆盖，也可能触发Using filesort并被迫回表 -
GROUP BY查询中漏掉任意一个分组字段或非聚合输出字段，就会回表——SELECT region, COUNT(*) FROM sales GROUP BY region要求索引必须含region，不能只靠WHERE条件字段 -
NULL值处理不明确：若WHERE status IS NULL，而索引列允许NULL，需用EXPLAIN验证是否真走索引
最容易被忽略的是：覆盖索引对 COUNT(*) 和深度分页（LIMIT 10000, 20）提升极大，但前提是 WHERE 能命中索引，且不带 * ——否则优化器宁可全表扫描，也不愿回表上万次。
