欢迎来到
“我知道平时一般不用，但我就是要考你” 系列
MySQL为什么选择B+树？
一、前言
在我们日常开发中，MySQL 用得最多的存储引擎是 InnoDB，而它默认的索引结构就是 B+树（B+Tree）。
那么问题来了：
✅ 为什么不是哈希表？
✅ 为什么不是二叉树？
✅ 为什么不是B树而偏偏是B+树？
这篇文章，深入浅出地聊一聊：MySQL 为什么选择了 B+树？
二、B+树的核心特点
简要特性：
- 所有数据都存储在叶子节点。
- 非叶子节点只存储键值（不存数据），用于索引查找。
- 所有叶子节点通过链表连接，范围查询效率极高。
- 每个节点可以存放多个 key，层级更少，查找路径更短。
👇 简化示意图如下：
三、为什么不是其他结构？
3.1 为什么不是二叉树？
- 二叉查找树（BST） 在数据不平衡时会严重退化成链表，查询效率变 O(log n) ➡ O(n)。
- 虽然可以用 AVL树 / 红黑树 做自平衡，但节点太小、层数太多，IO次数多，不适合磁盘存储。
缺点：磁盘友好性太差
3.2 为什么不是哈希索引？
- 哈希索引虽然查找快（O(1)），但它不支持范围查询。
- 比如你想查询
age between 20 and 30—— 哈希索引完全做不到。 - InnoDB 的主流查询场景中，范围查很常见。
缺点：不支持范围查询
3.3 为什么不是B树（Basic Tree）？
B树和B+树的区别在于：
| 特性 | B树 | B+树 |
|---|---|---|
| 数据存储 | 所有节点 | 只存储在叶子节点 |
| 查找路径 | 有点不统一 | 所有查找都走到底 |
| 范围查询 | 需要遍历多个分支 | 叶子链表一次扫完 |
| IO次数 | 相对较多 | 相对较少 |
B树和B+树对比图👇
所以，B+树相比 B树，更适合范围查询、磁盘IO少、叶子节点结构更稳定。
四、为什么适合磁盘存储场景？
磁盘访问的特性决定了一点：一次IO，要尽可能读多点内容！
- B+树的每个节点大小可以设计成与一个磁盘页大小一致（如16KB）。
- 一个节点里可以塞下上百个 key，大大降低了树的高度。
- 这样一来，查找某个值时最多只需 2~3 次磁盘 IO，极其高效！
举个栗子：
如果有 1000 万行数据，使用 B+树索引只需约 3 次磁盘IO，就能定位到目标值！
五、总结：为什么选择 B+树？
| 指标 | 是否满足？ | 说明 |
|---|---|---|
| 快速定位 | ✅ | 多叉树+低层级 |
| 范围查询 | ✅ | 叶子节点链表遍历 |
| 支持排序 | ✅ | 中序遍历天然有序 |
| IO友好 | ✅ | 每个节点可对应一个磁盘页 |
| 插入删除效率 | ✅ | 平衡性强，节点分裂/合并机制成熟 |
所以 MySQL 使用 B+树，是经过深思熟虑的权衡——
🌟 它并不是最优解，但它是 “适合数据库场景” 的最佳方案。
六、最后 ：MySQL索引一定是B+树吗？
答案是：
不是！
- InnoDB：主键索引 & 二级索引 👉 全是 B+树
- Memory 引擎：支持 Hash 索引
- FullText、Spatial 索引：使用倒排索引、R树等
所以选择什么索引结构，其实依赖于存储引擎和使用场景。
9786
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
