索引数据结构：B+树的原理与磁盘IO优化

咱们聊索引，绕不开B+树。说实话，市面上很多教材把它讲得太玄了。我今天就从一个实战工程师的角度，带你把它拆开揉碎，看看到底怎么个事儿。

为什么是B+树？不是B树，不是二叉树？

我刚开始做DBA的时候，也想过这个问题。你想想看，我们数据库里数据量动辄百万千万，甚至上亿。如果用二叉树，树的高度会非常高，每次查询都要做很多次磁盘IO。说白了，二叉树更适合内存里的数据结构。

而B+树，它的设计目标从一开始就是——减少磁盘IO次数。

我个人习惯把它理解成一个“宽矮胖”的树。每层能存放的分支非常多，这样一来，树的高度就能压得很低。

B+树的三大核心特性

嗯，这里咱们得细说。B+树有3个跟磁盘IO强相关的设计，你得牢记在心。

1. 只有叶子节点存数据：非叶子节点只存键值和指针。这么做的好处是啥？一个节点（也就是一个页）能放更多的索引条目，所以树更矮。
2. 叶子节点形成双向链表：所有数据都落在叶子层，而且叶子节点之间有指针连接。这就是为什么范围查询那么快——找到起点后，顺着链表往下扫就行了。
3. 页大小与磁盘块对齐：InnoDB默认的页大小是16KB，目的就是为了跟操作系统的磁盘块对齐。

深入磁盘IO优化

为什么B+树高度低就能优化？你得先明白磁盘IO的开销。

一次磁盘IO很慢。有多慢？大概是内存访问的几万倍。所以减少IO次数，就是提高性能的关键。B+树的策略很简单：让你每次IO都物尽其用。

举个例子。一个B+树节点就是一个页（16KB）。一次IO把这个页读取到内存，里面包含了上百个键值对。你可以在这个页内部用二分查找快速定位到下一个页的位置。

实操中你必须知道的两件事

1. 页的利用率和分裂

当插入数据时，如果某个页满了，就得分裂。分裂会产生两个页，并导致索引树做结构调整。

我见过最典型的错误：很多人以为分裂是好事，觉得树会变得更平衡。其实不然，频繁的分裂会导致大量的随机IO，严重影响写入性能。

怎么解决？

• 合理排序：让插入的数据尽量顺序写入。比如自增主键就能做到这一点。
• 调整填充因子：有些存储引擎允许你控制每个页的填充度。预留空间，可以减少分裂的频率。

2. 覆盖索引与回表

查询如果只用索引就能获取所有需要的数据，这就是覆盖索引。不需要去数据行里读取，效率极高。

反之：如果索引里没有你要的字段，就需要通过主键回表去取完整行，这就是一次随机IO。你想，如果查10万行就要做10万次随机IO，这个性能损耗非常大。

B+树 vs B树：到底差在哪？

对比维度	B+树	B树
数据存储位置	只有叶子节点存储数据	所有节点都存储数据
叶子节点结构	形成双向链表，方便范围遍历	节点之间无连接
范围查询性能	极高——找到起点后纵向+横向扫描	较低——需要多次从根节点递归遍历
插入/删除	可能触发页分裂或合并，但相对稳定	内部节点也会变动，调整更频繁
页利用率	非叶子节点可存放更多键值，树更矮	每个节点都存数据，分支数少，树更高

一句话总结：B+树是专门为磁盘IO设计的，B树适合并发高、频繁就地更新的场景。但在传统的关系型数据库里，B+树是的主流。

一个真实的案例

有一次我优化一个日志表，日增数据量大概200万行。原来的查询是按时间范围查的，巨慢。我看了下执行计划，每次查询都是全表扫描。为什么？因为时间字段上虽然有索引，但那个索引是二级索引，查询还是得回表。

改法很简单：把查询需要的字段全都加到索引里，形成覆盖索引。同时把主键改成自增ID，用B+树的顺序写特性来提升插入性能。

这优化前插入速率是每秒300行，优化后跑到了每秒2200行。查询耗时从原来的平均1.2秒降到了15毫秒。这就是B+树底层威力最直观的体现。

本章小结思维导图

把前面讲的核心知识点，我画成了一张SVG图。你看完应该就能串联起来。

给我记住这句

B+树优化磁盘IO的本质，就是用空间换时间，用更少的IO次数去查询更多的数据。

下次你建索引的时候，脑子里想一下B+树的层数，想一下页分裂的开销，想一下覆盖索引能帮你省掉多少次回表。这些思考才是你这个课程最值钱的地方。