避免回表的核心是使用覆盖索引，即SELECT、WHERE、ORDER BY、GROUP BY所有字段均落在同一二级索引中，EXPLAIN的Extra列显示“Using index”或“Using where; Using index”即表示成功避免回表。
直接结论：避免回表的核心是让查询「只走索引不查行」，即所有 SELECT 字段、WHERE 条件字段、ORDER BY 或 GROUP BY 字段，全部落在同一个二级索引的叶子节点中——这叫覆盖索引；只要 EXPLAIN 的 Extra 列出现 Using index，就说明成功避开了回表。
怎么用 EXPLAIN 确认是否真避开了回表
别信索引建了就生效，必须看执行计划里的 Extra 字段：
-
Using index→ ✅ 真覆盖，不回表 -
Using where; Using index→ ✅ 也覆盖，ICP + 覆盖同时发生 -
Using index condition→ ❌ 只用了索引下推，仍要回表取非索引字段 - 空值、
Using where、Using filesort→ ❌ 没覆盖，大概率在回表
特别注意：SELECT * 几乎永远触发不了 Using index，因为二级索引叶子节点不含所有字段；哪怕你建了 (a,b,c) 索引，SELECT * 也会让优化器放弃覆盖路径。
联合索引字段顺序怎么排才不白建
顺序不是堆字段，它决定能不能过滤、能不能覆盖、会不会失效：
- WHERE 中的等值条件（如
user_id = ?）放最左 - 范围条件（如
created_at > ?）紧接其后，它右边的字段只能用于覆盖，不能用于查找 -
SELECT字段（如status,amount）补在末尾；主键（如id）不用显式写，InnoDB 自动存 -
ORDER BY字段如果不在 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 < '2026-01-01' - 隐式类型转换：
WHERE mobile = 13812345678（mobile是VARCHAR）→ 改成WHERE mobile = '13812345678' - 左模糊查询：
WHERE name LIKE '%ton'→ 索引无法定位起点，优化器常退化为全表扫描 - SELECT 中含
TEXT/BLOB字段 → 覆盖索引立刻失效（前缀索引不参与覆盖判断）
哪怕索引定义完全匹配，只要 WHERE 或 SELECT 里出现上述任一情况，EXPLAIN 的 Extra 就不会显示 Using index。
覆盖索引的代价容易被低估
它不是越宽越好，写入和内存开销会真实上涨：
- 每多一个
VARCHAR(200)字段，B+ 树节点变大，buffer pool 缓存效率下降 -
INSERT/UPDATE/DELETE都要同步更新该索引，字段越多，写放大越明显 - 高频更新字段放进索引，可能让索引维护成本远超查询收益
真正关键的是：别为每个查询单独建索引，优先合并。比如已有 (a, b)，又常查 SELECT a, b, c WHERE a = ? AND b = ?，可扩展为 (a, b, c) 覆盖——但加之前先确认 c 是小字段，且业务上确实高频只查这三列。
