Using index出现在EXPLAIN的Extra列中才表示真正覆盖索引，即所有查询字段均从索引叶子节点获取而无需回表；Using index condition仅表示索引下推过滤，并非覆盖。
EXPLAIN里看到Using index才算真正覆盖
执行计划中的Using index是唯一可信信号，它表示MySQL直接从索引叶子节点取完所有数据，没触发回表。别被Using index condition骗了——那只是用了索引下推（ICP），WHERE部分在索引层过滤了，但SELECT字段仍要回表取。
常见误判场景：
- 查询含
SELECT *，哪怕索引建得再全，也必然回表 -
ORDER BY字段不在索引里，优化器可能放弃走覆盖索引，改用Using filesort+ 回表 - SELECT中用了函数，比如
UPPER(name)，即使name在索引中，也无法命中覆盖（MySQL 8.0+需显式建函数索引）
联合索引字段顺序必须匹配查询模式
不是把所有字段堆进索引就行，顺序错了等于白搭。核心原则：等值条件字段放最左，后续按SELECT和GROUP BY需要的字段补全。
例如高频查询：SELECT region, COUNT(*) FROM sales WHERE year = 2025 GROUP BY region
- 正确索引：
CREATE INDEX idx_year_region ON sales (year, region)——year等值过滤，region既是分组键又是输出列，全部覆盖 - 错误索引：
CREATE INDEX idx_region_year ON sales (region, year)——WHERE year = ...无法用最左前缀，索引基本失效 - 漏掉
region：哪怕year索引存在，GROUP BY region仍要回表取值，10万行就是10万次随机I/O
TEXT/BLOB字段和高区分度字段会破坏覆盖效果
一旦SELECT列表里出现TEXT或BLOB类型字段，覆盖索引立刻失效——这类字段不能完整存入索引页，最多支持前缀索引，但前缀索引不参与覆盖判断。
另一个隐形陷阱是低区分度字段放最左：
-
status只有'paid'/'pending'/'failed'三个值，如果建索引(status, user_id)，优化器大概率判定“扫太多行”，直接放弃走索引，退化为全表扫描 - 应优先把高区分度字段（如
user_id、order_id）放在前面，status放后面作过滤补充 - 若必须用
status做等值查询，可考虑加FORCE INDEX干预，但更治本的是重构索引顺序
GROUP BY和聚合查询对覆盖更敏感
大表GROUP BY慢，往往不是因为排序，而是回表。优化器要求极其严格：WHERE字段、GROUP BY字段、SELECT中所有非聚合字段，三者必须全部落在同一联合索引中，缺一不可。
比如查询：SELECT user_id, COUNT(*) FROM orders WHERE status = 'paid' GROUP BY user_id
- 只建
(status)索引 → 先扫出主键，再逐个回表取user_id→ 随机I/O爆炸 - 只建
(user_id)索引 → 无法过滤status，可能全索引扫描 - 必须建
(status, user_id)→ 过滤+分组+输出全在索引页内完成 - 如果还要
MAX(created_at)，就得扩展为(status, user_id, created_at)，但注意created_at类型是否支持高效索引（DATETIME可以，TEXT不行）
真正难的不是建索引，是把查询语句、字段类型、区分度、执行计划这四件事拧成一股绳——漏掉任意一个环节，Using index就永远不会出现在Extra里。
