覆盖索引真正生效的唯一信号是explain的extra列显示using index；using index condition仅表示索引下推，仍需回表，未实现覆盖。
覆盖索引真正生效的唯一信号是 EXPLAIN 的 Extra 列显示 Using index；其他任何提示（比如 Using index condition）都不代表避免了回表。
怎么确认你的查询真的用了覆盖索引？
别靠猜，也别看 key 列有没有值——关键只看 Extra 列：
-
Using index✅：所有字段都从索引叶子节点直接读出，没回表 -
Using index condition❌：只做了索引下推（ICP），WHERE 条件在索引层过滤了，但 SELECT 字段仍要回表取 - 空值或
Using where; Using filesort等 ❌：大概率没走覆盖，甚至根本没走索引
执行前务必加 EXPLAIN：
EXPLAIN SELECT user_id, status FROM orders WHERE user_id = 1001 AND status = 'paid';
如果返回的 Extra 不是 Using index，那就说明索引定义漏了字段、顺序错了，或者查询本身破坏了覆盖条件。
为什么建了索引却没触发覆盖？常见失效点
覆盖索引不是“建了就能用”，三个硬性条件缺一不可：
- SELECT 的每个字段（包括 WHERE、ORDER BY、GROUP BY 中涉及的非聚合列）必须全部出现在同一个二级索引中
- 不能对索引字段使用函数或表达式，例如
UPPER(name)、DATE(created_at)—— MySQL 8.0+ 需显式建函数索引才可能覆盖 - 不能有隐式类型转换，比如
name = 123（name是 VARCHAR），会导致索引失效
另外两个隐形杀手：
-
SELECT *永远无法被二级索引覆盖（除非你建的是主键索引本身） - 只要 SELECT 列里包含
TEXT或BLOB类型字段，覆盖立刻失效——这类字段不完整存入索引页，前缀索引也不参与覆盖判断
联合索引字段顺序怎么排才真正覆盖？
顺序不是按“查询写法”来，而是按“最左前缀 + 覆盖延伸”逻辑组织：
- 等值查询字段（WHERE 中的
=或IN）必须放最左，且连续 - 后续字段用于覆盖 SELECT、ORDER BY、GROUP BY 所需列，顺序要匹配访问模式
例如高频查询：
SELECT region, COUNT(*) FROM sales WHERE year = 2025 GROUP BY region;
正确索引是：
CREATE INDEX idx_year_region ON sales (year, region);
错误写法包括：
-
CREATE INDEX idx_region_year ON sales (region, year)→WHERE year =无法用最左前缀，索引基本失效 -
CREATE INDEX idx_year ON sales (year)→ 缺region，GROUP BY 和 SELECT 都得回表，10 万行就是 10 万次随机 I/O
覆盖索引不是越多越好，空间和写性能代价很实在
把所有字段塞进一个索引，短期看着省事，长期会反噬：
- 索引体积膨胀：每多一个
VARCHAR(200)字段，B+ 树节点变大，buffer pool 缓存命中率下降 - 写操作更慢：每次
INSERT/UPDATE/DELETE都要同步更新该索引，字段越多越卡 - 缓冲池压力：大索引挤占
innodb_buffer_pool_size，真实数据页反而容易被淘汰
真正该做的，是按核心查询路径收敛字段——比如订单表高频查 user_id、status、amount，那就建 (user_id, status, amount)，而不是把 remark、ext_data 全塞进去。
最常被忽略的一点：低区分度字段（如只有 3 个值的 status）绝不能放最左。优化器一看“扫太多行”，直接放弃走索引。高区分度字段（如 user_id）必须前置，status 放后面作过滤补充。
