判断是否走覆盖索引需看explain的extra列：出现using index或using where; using index表示真覆盖、不回表；using index condition仅索引下推、仍需回表；空值、using where、using filesort则未覆盖。
能彻底避免，但前提是查询的每列、每个条件、每个排序/分组字段，都必须被同一个二级索引“咬住”——漏一个，就回表。
怎么一眼确认当前查询是否真走覆盖索引
别信 type 是 ref 或 range，只看 EXPLAIN 输出里的 Extra 列：
-
Using index→ ✅ 真覆盖，不回表 -
Using where; Using index→ ✅ 也覆盖，ICP + 覆盖同时生效 -
Using index condition→ ❌ 只用了索引下推，仍要回表取非索引字段 - 空值、
Using where、Using filesort→ ❌ 没覆盖，大概率在回表
特别注意：SELECT * 几乎永远触发不了 Using index，因为二级索引叶子节点不含所有字段；哪怕你建了 (a,b,c) 索引，SELECT * 也会让优化器放弃覆盖路径。
联合索引字段顺序怎么排才真正覆盖 WHERE + SELECT
顺序不是堆字段，而是按执行逻辑分层排布：
- 最左：WHERE 中的等值条件列（如
user_id = ?） - 中间：WHERE 中的范围条件列（如
created_at > ?），它右边的字段只能用于覆盖，不能用于查找 - 末尾：SELECT 中需要返回的非条件字段（如
status,amount），主键（如id）不用显式写，InnoDB 自动存 - 如果还有
ORDER BY created_at且该字段不在 WHERE 条件里，也得塞进末尾，否则触发Using filesort
反例：INDEX idx_created_status (created_at, status) 对 WHERE status = 1 无效——跳过最左列，整个索引用不上。
哪些写法会让覆盖索引“悄悄失效”
建了索引 ≠ 生效。这些常见操作会让 MySQL 直接弃用覆盖路径：
- 对索引字段用函数：
WHERE YEAR(created_at) = 2025→ 改成WHERE created_at >= '2025-01-01' AND created_at - 隐式类型转换：
WHERE mobile = 13812345678（mobile是VARCHAR）→ 改成WHERE mobile = '13812345678' - LEFT 模糊：
WHERE name LIKE '%ton'→ 索引无法定位起点，优化器常直接全表扫 - TEXT/BLOB 字段直接加进索引 → 建索引会失败或被静默截断，必须用前缀，如
email(100)
哪怕索引定义完全匹配，只要 WHERE 或 SELECT 里出现上述任一情况，EXPLAIN 的 Extra 就不会显示 Using index。
覆盖索引真正的难点不在“建”，而在“对齐”
你要让索引字段顺序、类型、长度，和实际查询的 WHERE 条件顺序、SELECT 字段列表、ORDER BY 依赖完全咬合。漏掉一个隐式转换（比如字符串比较时的 collation 不一致），或者多一个 NULL 判断，都可能导致优化器弃用覆盖索引。更隐蔽的是：高频更新字段（如 status、updated_at）放进覆盖索引，写放大真实存在，读写比低于 5:1 时就得重新权衡。
