MySQL（特别是其默认存储引擎 InnoDB）使用 B+ 树 而不是 B 树 作为索引结构，主要是因为 B+ 树在数据库系统中具有以下几个关键优势，更适合磁盘 I/O 和范围查询等常见数据库操作：
1. 所有数据都存储在叶子节点
- B+ 树 ：内部节点只存储索引键（用于导航），实际的数据（或指向数据的指针）全部存储在叶子节点。
- B 树：每个节点（包括内部节点）都可能存储数据。
优势：
- 叶子节点可以形成一个有序链表 ，便于高效执行范围查询 （如
WHERE id BETWEEN 10 AND 100）。 - 内部节点不存数据，可以容纳更多键，从而降低树的高度，减少磁盘 I/O 次数。
2. 更高的扇出（Fan-out） → 更矮的树
- 因为 B+ 树的内部节点只存键（不存数据），每个页（如 InnoDB 的 16KB 页）能存放更多键。
- 假设一个页能存 1000 个键，那么：
- 2 层 B+ 树可索引约 100 万条记录（1000 × 1000）
- 3 层可索引约 10 亿条记录
优势：树更"矮胖"，查找任意记录最多只需 2～3 次磁盘 I/O，性能稳定。
3. 范围查询效率高
- B+ 树的叶子节点通过指针顺序连接，遍历范围数据时只需顺序读取叶子节点。
- B 树的范围查询需要中序遍历整棵树，效率低且难以优化。
优势 ：对 ORDER BY、GROUP BY、范围扫描等操作非常友好。
4. 更适合磁盘存储模型
- 数据库以页（Page） 为单位读写磁盘（InnoDB 默认 16KB）。
- B+ 树的设计天然契合"一次读取一页"的 I/O 模型。
- 所有数据集中在叶子层，缓存和预读策略更容易优化。
对比总结：
表格
| 特性 | B 树 | B+ 树 |
|---|---|---|
| 数据存储位置 | 所有节点 | 仅叶子节点 |
| 内部节点是否存数据 | 是 | 否（只存索引键） |
| 叶子是否链式连接 | 否 | 是 |
| 范围查询效率 | 较低 | 高 |
| 树高度 | 相对较高 | 更矮（因扇出更大） |
| 适合场景 | 内存查找、单点查询为主 | 磁盘存储、范围查询、数据库索引 |
补充说明
- MySQL 的 MyISAM 引擎也使用 B+ 树。
- 其他数据库（如 PostgreSQL、Oracle、SQL Server）同样普遍采用 B+ 树作为主索引结构。
- 哈希索引适用于等值查询（如 Memory 引擎），但不支持范围查询，因此不适合作为主索引。
结论 ：
MySQL 使用 B+ 树而非 B 树，是因为 B+ 树在磁盘 I/O 效率、范围查询性能、树高控制等方面更契合关系型数据库的实际需求。