MySQL 索引入门：从 B+ 树到慢查询优化

刚接手一个慢查询时，很多人第一反应是加索引，但索引为什么能让查询变快、什么时候又会失效，答案都在它的底层结构里。本文从 B+ 树讲起，再落到慢查询优化的具体做法。

一、为什么需要索引

没有索引时，数据库要逐行扫描整张表才能找到目标数据，数据量越大越慢。索引相当于书的目录：先通过目录定位到页码，再翻到正文，扫描范围从全表缩小到几行。

二、B+ 树：索引的底层结构

MySQL 的 InnoDB 索引主要用 B+ 树实现。它有三个关键特点：第一，只有叶子节点存放数据，非叶子节点只存放键值和指针，起到导航作用；第二，叶子节点之间用链表连接，范围查询可以顺序扫描；第三，树高通常只有三到四层，一次点查只需要三四次磁盘 IO。

和 B 树相比，B+ 树的数据全部集中在叶子层，非叶子节点更“瘦”，同样大小的节点能装下更多键值，树更矮更宽，查询更稳定；和哈希索引相比，B+ 树支持范围查询和排序，而哈希只擅长等值查询。

三、聚簇索引与二级索引

InnoDB 的主键索引就是聚簇索引，叶子节点直接存放整行数据。二级索引的叶子节点存放的是主键值，查到主键后再回表查聚簇索引才能拿到完整数据。如果查询的列全部包含在索引里，就能用覆盖索引避免回表，这是常见的优化手段。

四、最左前缀与索引失效

联合索引遵循最左前缀原则：对（a，b，c）建立联合索引，查询条件带 a 才能用上，跳过 a 直接查 b 就用不上；遇到范围条件后，后面的列也会失效。常见的失效场景还有：对索引列使用函数或运算、发生隐式类型转换、LIKE 以百分号开头、OR 的一侧没有索引。

五、慢查询优化三步

第一步，用 EXPLAIN 看执行计划，重点关注 type、key、rows 和 Extra。type 为 ALL 说明全表扫描，ref 或 range 通常是好信号；Extra 出现 Using filesort 或 Using temporary 说明需要额外排序或临时表，值得警惕。

第二步，定位慢 SQL。开启慢查询日志，定期用工具聚合分析，优先处理执行次数多、平均耗时长的语句，而不是只盯着单条最慢的。

第三步，对症下药。缺索引就补合适的索引；索引选错就改写 SQL 或用强制索引；深分页避免大 OFFSET，改用主键范围或游标分页；冷数据及时归档，让热表保持精简。

六、索引不是越多越好

索引也要占用磁盘空间，每次写入都要维护，索引太多还会让优化器选错。建索引前先想清楚查询模式，定期清理无用索引，读写比不同，索引策略也不同。

理解 B+ 树只是起点。真正做好慢查询优化，需要把执行计划、索引结构和业务查询模式结合起来看，先定位再动手，优化才有针对性。