覆盖索引指索引包含查询所需全部字段，可避免回表；explain中extra显示“using index”即生效，否则仍需回表。
EXPLAIN里看到Using index才算真正避免回表
回表不是“走了索引就没事了”，而是看MySQL是否真的只靠索引就拿到了全部数据。关键证据在EXPLAIN输出的Extra列：Using index表示覆盖生效；Using index condition只是用了索引下推（ICP），仍要回表；Using where或空白则大概率回表。
常见误判场景：
- 查
SELECT *，哪怕WHERE条件命中索引，也必然回表——二级索引叶子节点不存所有字段 - ORDER BY字段不在索引中，或顺序与索引不一致，MySQL可能放弃覆盖而走
Using filesort并回表 - WHERE里用了
IS NULL且列允许NULL，优化器有时会跳过索引，必须用EXPLAIN验证
联合索引字段顺序必须匹配查询模式
覆盖索引不是把字段堆进索引就行，顺序决定它能不能被用上。核心原则是：等值条件字段放最左，范围条件放中间，SELECT和ORDER BY字段补在最后。
例如这个查询：
SELECT id, status, created_at FROM order WHERE user_id = 123 AND created_at > '2025-01-01' ORDER BY status;
对应有效索引应为：INDEX idx_user_created_status (user_id, created_at, status)。注意：created_at是范围条件，它右边的status仍可用于覆盖，但无法用于索引查找；如果把status放最左，WHERE user_id = ?就用不上这个索引。
容易踩的坑：
- 高区分度字段（如email）放在第二位，而第一列（如role）区分度低，导致等值查询时索引选择性差
- 把
updated_at这种高频更新字段塞进覆盖索引，写放大严重，读写比低时不划算
TEXT/BLOB和函数会让覆盖索引悄悄失效
MySQL不允许TEXT、BLOB类型字段直接参与索引，哪怕你写了ALTER TABLE t ADD INDEX idx_xxx (text_col)，建索引也会失败，或自动截断为前缀索引（如text_col(100)）。一旦SELECT里包含未加前缀的TEXT字段，覆盖就断了。
同样，SELECT中用了表达式或函数，比如SELECT UPPER(name)，即使name在索引里，也无法命中覆盖——除非MySQL 8.0+且你显式创建了函数索引：INDEX idx_upper_name ((UPPER(name)))。
其他隐形破坏者：
- 隐式类型转换：比如
WHERE phone = 13800138000（phone是VARCHAR），MySQL可能放弃索引 - 字符集或collation不一致，导致索引无法对齐，优化器弃用覆盖
深分页和COUNT(*)是覆盖索引最见效的两个场景
这两个场景天然适合覆盖索引，因为它们要么只关心主键，要么只统计行数，对字段要求极简。
比如深分页：SELECT * FROM article ORDER BY id LIMIT 1000000, 20。优化做法是先用覆盖索引查出id：SELECT id FROM article ORDER BY id LIMIT 1000000, 20（只要id在索引里，就能Using index），再用这些id做主键关联查完整数据。避免上百万次随机IO回表。
COUNT(*)统计更简单：只要WHERE条件能走索引，且没SELECT *，MySQL就能纯索引扫描计数，速度远超全表扫描。
真正难的不是建索引，而是让索引字段、查询写法、排序逻辑、字符集、NULL处理全部咬合——漏掉任意一环，EXPLAIN里就看不到Using index。
