MySQL B+ Tree 机制与算法详解

Wed, 29 Apr 2026 00:00:00 +0800

为什么数据库普遍选择 B+ Tree

如果只从算法课本看，查找一个有序集合有很多选择：数组可以二分，哈希表可以做到平均 O(1)，红黑树、AVL 树可以做到 O(logN)。但数据库的核心问题不是“CPU 内存里怎么找”，而是“磁盘或 SSD 上的数据怎么少读几次”。

MySQL 的 InnoDB 存储引擎把表数据和索引组织成页。默认情况下，一个页通常是 16KB。一次查询如果每深入一层索引就需要读取一个页，那么树的高度越低，I/O 次数就越少。B+ Tree 的核心优势就在这里：

所以，B+ Tree 不是为了在理论复杂度上压倒所有结构，而是为了适配数据库最昂贵的资源：随机 I/O。

普通二叉搜索树每个节点最多两个孩子。即使它保持平衡，一千万条数据的高度也大约是二十多层。放在内存里问题不大，放在数据库里就意味着一次查找可能触发很多次随机页读取。

B Tree 和 B+ Tree 解决的是“分叉太少”的问题。一个节点可以保存多个 key 和多个孩子指针。例如节点中有这些分隔 key：

[10 | 20 | 30]

它可以把搜索空间分成四段：

(-∞, 10) [10, 20) [20, 30) [30, +∞)

这样，一个节点不是二选一，而是多路分发。只要一个页中能放下足够多的 key 和指针，树的高度就会非常低。

B+ Tree 相比 B Tree 又进一步做了一个重要取舍：非叶子节点不存放完整数据记录，只存放用于导航的 key 和子节点页号；所有完整记录都放在叶子节点。这样非叶子节点更小，能容纳更多 key，树也就更矮。

一棵典型 B+ Tree 可以分成三类节点：