一、基本定义
| 特性 | B树 | B+树 |
|---|---|---|
| 全称 | Balance Tree | Balance+ Tree |
| 提出时间 | 1970年（Rudolf Bayer, Edward M. McCreight） | B树的变种，主要改进用于数据库和文件系统 |
| 本质 | 多路平衡查找树 | 在B树基础上，将数据全部放在叶子节点，内部节点只存索引 |
二、核心结构区别
1. 数据存储位置
B树：
- 每个节点（包括内部节点和叶子节点）都存储键值和数据指针（或实际数据）
- 数据可能分布在所有节点中
B+树：
- 只有叶子节点存储数据指针（或实际数据）
- 内部节点只存储键值（索引），不存储数据，仅用于导航
2. 叶子节点结构
B树：
- 叶子节点之间通常没有链表连接（虽然有些实现可能加链表，但非标准）
B+树：
- 所有叶子节点通过指针连接成链表
- 通常形成双向链表，便于范围查询
三、节点结构图示
B树节点（假设阶数m=4，最多3个键）
内部节点: [key1|data1] [key2|data2] [key3|data3]
/ | \ | \
子节点 子节点 子节点 子节点 子节点
- 每个键都附带数据指针
B+树节点
内部节点（只存键）：
内部节点: [key1] [key2] [key3]
/ | \ \
子节点 子节点 子节点 子节点
叶子节点（存键+数据+链表指针）：
叶子节点: [key1|data1] -> [key2|data2] -> [key3|data3] -> ...
|
(指向下一个叶子节点的指针)
四、查找操作对比
查找单个键（例如查找 key = 50）
B树：
- 从根节点开始
- 在节点内二分查找或顺序查找
- 如果找到 key，立即返回该节点的数据（可能在内部节点就命中）
- 否则进入对应的子节点继续
特点：可能在非叶子节点就找到结果，查找路径可能较短。
B+树：
- 从根节点开始
- 在内部节点二分查找，只用于导航
- 必须一直找到叶子节点
- 在叶子节点中查找 key 并获取数据
特点：所有查找都必须走到叶子节点，查找路径长度固定（等于树高）。
范围查询（例如查找 20 ≤ key ≤ 60）
B树：
- 需要先找到下限键，然后进行中序遍历
- 在遍历过程中，需要在内部节点和叶子节点之间来回切换
- 效率较低，且实现复杂
B+树：
- 先找到下限键所在的叶子节点
- 利用叶子节点之间的链表顺序向后遍历
- 直到超过上限为止
- 效率极高，这是B+树最重要的优势之一
五、插入与删除操作对比
| 操作 | B树 | B+树 |
|---|---|---|
| 插入 | 可能在任何节点分裂，分裂后键值上移 | 只在叶子节点插入数据，分裂时键值上移到父节点（但父节点不存数据） |
| 删除 | 可能在任何节点合并或借用键值，删除内部节点键值时需要处理子节点 | 只从叶子节点删除数据，内部节点的键值可能保留作为索引（即使对应数据已删） |
| 节点利用率 | 相对较低（键和数据混存） | 更高（内部节点只存键，可以存储更多键，树的高度更低） |
| 分裂频率 | 节点存数据，键数量少，分裂更频繁 | 内部节点只存键，可容纳更多键，相对不易分裂 |
六、性能特点对比
| 维度 | B树 | B+树 |
|---|---|---|
| 单点查找 | 平均更快（可能中途命中） | 稳定 O(logₘN)，必须到叶子层 |
| 范围查询 | 较差（需中序遍历） | 极好（利用叶子链表） |
| 磁盘I/O | 可能更少（非叶子节点命中时） | 稳定（树高通常更低） |
| 缓存效率 | 一般 | 更高（内部节点更小，可缓存更多索引） |
| 顺序访问 | 不支持 | 支持（叶子链表） |
| 空间利用率 | 键+数据占用节点空间 | 内部节点纯索引，空间利用率更高 |
七、实际应用场景
B树的典型应用
- 较少使用在现代数据库和文件系统中
- 一些旧的或特定的嵌入式数据库（如某些NoSQL存储引擎）
- 需要频繁单点查找且范围查询极少的场景
B+树的典型应用
- 主流关系型数据库：MySQL（InnoDB引擎）、PostgreSQL、Oracle
- 文件系统：NTFS、ReiserFS、XFS等
- 大多数现代数据库索引（聚簇索引、辅助索引）
- 需要高效范围查询、分页查询、排序操作的场景
补充说明：MySQL的InnoDB引擎默认使用B+树作为索引结构，主要原因就是B+树对范围查询、排序、分页支持更好，且磁盘I/O更稳定可控。
八、为什么 B+ 树在数据库领域更流行？
- 范围查询效率高：数据库常见的
BETWEEN、>、<、ORDER BY、分页查询等，B+树通过叶子链表可高效完成。 - 磁盘I/O更友好：
-
- 内部节点只存键，同样大小的磁盘块可以存储更多的键，使得树的高度更低
- 查找过程中，非叶子节点可以全部缓存在内存中，减少磁盘I/O
- 数据存储稳定：所有数据都在叶子节点，查询复杂度稳定，便于性能分析和预测。
- 全表扫描友好：直接遍历叶子节点链表即可，无需复杂的树遍历。
- 缓存命中率高：内部节点紧凑，更容易被缓存。
九、总结对比表
| 对比项 | B树 | B+树 |
|---|---|---|
| 数据存储位置 | 所有节点 | 仅叶子节点 |
| 内部节点内容 | 键 + 数据指针 | 仅键 |
| 叶子节点是否连接 | 通常不连接 | 有链表连接 |
| 单点查找 | 可能非叶子命中 | 必须到叶子 |
| 范围查询 | 慢（需中序递归） | 快（链表遍历） |
| 树高 | 较高（节点存数据） | 较低（内部节点存更多键） |
| 典型应用 | 较少，特定场景 | 主流数据库、文件系统 |
如果需要，我可以进一步为你讲解 B+树在MySQL InnoDB中的具体实现（聚簇索引 vs 辅助索引），或者深入说明 B树/B+树的插入分裂与删除合并的具体过程。
面试回答
B+ 树和 B 树都是平衡的多路搜索树，但 B+ 树可以看作是 B 树的一种‘进化版’。它们在磁盘 I/O 优化这个目标上是一致的，但 B+ 树在结构设计上做了几个关键改进，让它在数据库和文件系统里应用更广。
1. 数据存储位置不同（最核心的区别）
- B 树：所有节点（包括根节点、内部节点、叶子节点）都存数据。也就是说，你搜一个值，可能在根节点就找到了，不一定要到叶子节点。
- B+ 树：只有叶子节点存数据，内部节点只存索引（也就是键值和指向下一层的指针）。
这个差异带来的好处是：B+ 树的内部节点能存更多的索引项，同样大小的磁盘块，B+ 树的分叉数（阶数）更高，树的高度就更低。树越低，查询时磁盘 I/O 次数就越少，这对数据库来说非常关键。
2. 叶子节点结构不同（影响范围查询）
- B 树：叶子节点之间是没有指针连接的，相互独立。
- B+ 树：所有叶子节点用指针串成一个有序链表。
这个设计让 B+ 树做范围查询特别快。比如你查‘id between 10 and 20’，B+ 树只需要找到 10 所在的叶子节点，然后顺着链表往后遍历就行了。而 B 树要做中序遍历，需要不断回溯到父节点再下来，随机I/O更多，性能差不少。这也是为什么 MySQL 的 InnoDB 引擎用 B+ 树而不是 B 树的原因 (业务里范围查询太常见了)
3. 查询效率的稳定性不同
- B 树：数据分散在各层，查询时间不稳定，好的情况 O(1) 就找到了，坏情况要到叶子层。
- B+ 树：所有数据都在叶子节点，每次查询都必须从根走到叶子，路径长度固定，所以查询时间是稳定的 O(log n)。
结合上面三点，B+ 树在磁盘 I/O 更少、范围查询更快、查询时间稳定这三个维度上都优于 B 树。而且B+ 树内部节点只存键值，不存数据，数据都在叶子节点，这样缓存命中率更高——内部节点可以常驻内存，大部分查询只需要一次叶子节点的磁盘 I/O。B 树虽然在某些点查询上可能更快（比如数据在上层就命中了），但综合来看，B+ 树更适合大规模数据、磁盘存储、高并发的场景，所以主流数据库都选它。
追加：那 B 树还有用吗？
B 树也不是完全没用了。在一些非磁盘存储、或者点查询特别多且不需要范围查询的场景，B 树还是有优势的，比如某些内存数据库。但整体来说，在磁盘数据库这块，B+ 树是绝对的主流。
