InnoDB 存储引擎为什么选择 B+树而不是 B树作为索引结构?_innodb为什么使用b+不使用b-优快云博客

本文链接：https://blog.youkuaiyun.com/wamp0001/article/details/149033354

InnoDB 存储引擎选择 B+树 而不是 B树作为索引结构，主要基于两者在数据存储、磁盘 I/O、范围查询、并发控制等方面的差异。以下是两者的对比及 B+树的优势分析：

数据存储位置
- B树的 所有节点（包括内部节点和叶子节点） 都存储数据（键值和数据指针）。
- 例如，主键和对应的数据记录可能同时存在于内部节点和叶子节点中。
范围查询效率
- B树的范围查询需要从根节点开始，逐层跳转到目标节点，再遍历子节点。
- 由于数据分散在多个节点中，范围查询需要多次回溯和跳跃，效率较低。
磁盘 I/O 性能
- B树的节点存储数据和键值，导致每个节点存储的数据量较少，树的高度较高。
- 树的高度越高，查询时需要的磁盘 I/O 次数越多，性能越差。
查询稳定性
- B树的查询路径可能因数据分布不同而变化。例如，某些数据可能在根节点直接命中（时间复杂度 O(1)），而其他数据需要遍历多层节点（时间复杂度 O(log n)），导致查询性能不稳定。
并发控制
- B树的节点分裂和合并操作涉及多个层级的节点，锁的粒度较大，容易引发锁冲突，影响并发性能。

数据存储位置
- 非叶子节点仅存储键值和子节点指针，不存储数据。
- 叶子节点存储所有数据（键值和数据指针），且所有叶子节点通过双向链表连接。
范围查询效率
- B+树的范围查询（如 BETWEEN, >, <）可以通过叶子节点的双向链表 顺序遍历，无需多次跳转内部节点，效率极高。
- 例如，查询 id BETWEEN 100 AND 200 可直接从叶子节点的链表中顺序扫描。
磁盘 I/O 性能
- 由于非叶子节点仅存储键值，每个节点可以容纳更多键值（扇出更高），树的高度更低。
- 例如，B+树的树高通常为 3-4 层，而 B树的树高可能更高，因此 B+树的磁盘 I/O 次数更少。
查询稳定性
- 所有查询最终都必须到达叶子节点，路径长度一致，查询性能稳定。
- 例如，无论数据存储在根节点还是叶子节点，查询时间复杂度均为 O(log n)。
并发控制
- B+树的叶子节点链表结构支持高效的范围查询和顺序访问，锁的粒度较小，减少了锁冲突的可能性。
- 节点分裂和合并操作集中在叶子节点，对上层节点的影响较小，适合高并发场景。

更适合磁盘 I/O
- B+树的非叶子节点仅存储键值，每个节点可以存储更多键值，降低树高，减少磁盘 I/O 次数。
- 例如，假设每个节点可以存储 1000 个键值，则 B+树的树高为 3 层即可支持 10^9 条数据（1000^3 = 1e9），而 B树可能需要更高的树高。
高效范围查询
- 数据库中常见的范围查询（如 WHERE id > 100）在 B+树中可以通过叶子节点的链表直接顺序扫描，而 B树需要多次跳转内部节点，效率较低。
稳定的查询性能
- B+树的所有查询路径长度相同，避免了 B树中因数据分布不均导致的查询性能波动。
并发控制优化
- B+树的叶子节点链表结构减少了锁冲突的可能性，适合高并发的 OLTP（在线事务处理）场景。

B树的适用场景：
B树更适合 内存数据库 或 哈希索引 无法覆盖的场景（如频繁的单点查询），但对范围查询和磁盘 I/O 性能要求较低的情况。
B+树的适用场景：
B+树是 关系型数据库（如 MySQL InnoDB） 的首选索引结构，尤其适合以下场景：
1. 大规模数据存储（通过降低树高减少磁盘 I/O）。
2. 高频范围查询（通过叶子节点链表高效遍历）。
3. 高并发事务处理（通过减少锁冲突提升并发性能）。