MySQL 使用 B+ 树作为索引数据结构，而不是 B 树，主要基于数据库系统的特性（如磁盘 I/O、范围查询、数据存储方式）对索引结构的优化需求。下面先分别介绍 B 树和 B+ 树，再解释 MySQL（特别是 InnoDB 引擎）选择 B+ 树的原因。
什么是 B 树？
B 树（B-Tree）是一种平衡的多路搜索树，常用于文件系统和数据库索引。它的主要特点：
- 节点存储键值 + 数据：每个节点既存储索引键（key），也存储对应的数据（data）或数据指针。
- 所有节点都在同一层：从根节点到叶子节点的路径长度相同，保证了查询的稳定性。
- 节点内键值有序：便于在节点内部进行二分查找。
- 每个节点可以有多个子节点（多路），降低树的高度。
B 树的查询过程：从根节点开始，通过比较键值找到对应的子节点，直到找到目标键所在的节点，若该节点存储了数据，则直接返回。查询可能在非叶子节点就结束（如果目标键在非叶子节点中）。
什么是 B+ 树？
B+ 树是 B 树的变体，在数据库索引中应用更广泛。它的主要特点：
- 非叶子节点只存储键值，不存储数据：所有数据都存储在叶子节点中。
- 叶子节点包含所有键值及数据指针，且通过指针连接成有序链表：便于范围查询和顺序遍历。
- 每个非叶子节点可以存储更多键：由于不存数据，节点能容纳更多索引项，树更矮，减少磁盘 I/O。
- 查询必须到达叶子节点：所有查询路径长度相同，性能稳定。
B+ 树的查询过程：必须从根节点走到叶子节点才能找到数据。叶子节点的链表结构使得范围查询只需找到起始叶子节点，然后沿链表顺序扫描即可。
MySQL 为什么选择 B+ 树而不是 B 树？
MySQL 的 InnoDB 存储引擎默认使用 B+ 树作为索引结构，原因如下：
1. 磁盘 I/O 次数更少
- B+ 树的非叶子节点不存储数据，每个节点能存储的键值数量远多于 B 树。这意味着在相同数据量下，B+ 树的高度更低（通常 2~3 层），查询时需要的磁盘 I/O 次数更少。
- 数据库索引通常存储在磁盘上，每次读取节点相当于一次磁盘 I/O，减少 I/O 次数对性能至关重要。
2. 范围查询和排序效率更高
- B+ 树的叶子节点通过指针形成有序链表，可以轻松支持范围查询（如
WHERE id > 100）和排序。只需找到起始叶子节点，然后沿链表顺序遍历即可，无需回溯到父节点。 - B 树要实现范围查询，需要在中序遍历时反复在树中上下移动，效率较低。
3. 查询性能更稳定
- B+ 树的所有查询都必须到叶子节点才能获取数据，因此每次查询的 I/O 次数基本相等（树的高度），性能稳定。
- B 树的查询可能在非叶子节点就返回，也可能需要到叶子节点，性能波动较大，不利于数据库优化器进行成本估算。
4. 数据存储更集中
- B+ 树的所有数据都存储在叶子节点，且叶子节点之间紧密连接，有利于利用磁盘预读特性，一次 I/O 读取更多数据。
- B 树的数据分散在各个节点，可能导致随机 I/O 增多。
5. 更好的缓存利用率
- 由于非叶子节点只存键值，占用空间小，可以更多地缓存在内存中，减少磁盘访问。
综上所述，B+ 树在磁盘 I/O、范围查询、性能稳定性等方面更适合数据库索引的需求，因此 MySQL（InnoDB）采用 B+ 树作为索引结构。