MySQL 索引深度解析：B+ 树、覆盖索引与慢查询治理

B+ 树为什么适合磁盘

InnoDB 聚簇索引是一棵 B+ 树：

• 非叶子节点只存键，扇出大，树高低（通常 3～4 层千万行）
• 叶子节点链表相连，范围扫描 BETWEEN、ORDER BY 友好
• 数据行存在主键叶子页；二级索引叶子存 主键值，需要回表

聚簇索引 vs 二级索引

查询 WHERE user_id = 1 若只有 user_id 二级索引，流程：

1. 在二级索引树定位 user_id=1 的叶子
2. 拿到主键 id 列表
3. 回表到聚簇索引取完整行（除非覆盖索引）

覆盖索引（Covering Index）

若查询列全部在索引里，无需回表：

-- 索引 idx_user_status (user_id, status, created_at)
SELECT status, created_at
FROM orders
WHERE user_id = 100 AND status = 1;

EXPLAIN 里 Extra: Using index 即覆盖索引，线上性能提升非常明显。

联合索引与最左前缀

索引 (a, b, c) 可高效支持：

• a
• a, b
• a, b, c

不能跳过左侧列单独用 b（除非优化器 index skip scan，版本相关）。

设计原则：等值过滤列放前，范围列放后；区分度高的列靠前。

EXPLAIN 要看什么

EXPLAIN SELECT * FROM posts WHERE slug = 'hello'\G

关注：

• type：ALL 全表扫描要警惕，目标 ref / range / const
• key：实际使用的索引
• rows：估算扫描行数
• Extra：Using filesort / Using temporary 考虑改写 SQL 或加索引

慢查询治理流程

1. 开启 slow_query_log，阈值 1s（按业务调）
2. pt-query-digest 或云监控聚合 TOP SQL
3. EXPLAIN + 必要时 SHOW PROFILE
4. 加索引 / 改写 / 拆表 / 缓存，避免盲目加索引（写放大、占空间）

小结

索引不是「列上加个 KEY」了事，而是 用 B+ 树换磁盘 IO。理解回表与覆盖索引后，联合索引顺序才能一次设计对，少踩「建了索引仍然慢」的坑。