MySQL 选择 B+ 树作为索引结构，主要是基于数据库系统的实际使用场景和硬件特性（特别是磁盘 I/O）的综合考量。以下是核心原因分析：
1. 磁盘 I/O 优化（最关键因素）
- 减少磁盘访问次数 ：B+ 树具有 矮胖的多叉结构，每个节点可以存储大量键值，显著降低树的高度（通常 3-4 层即可存储千万级数据）。查询时只需几次磁盘 I/O，而二叉树类结构（如 AVL 树）在数据量大时高度剧增，会导致频繁磁盘访问。
- 利用磁盘预读特性：磁盘按页（通常 4KB）读写，B+ 树的节点大小常设计为页的整数倍（如 16KB），一次 I/O 能加载一个完整节点，充分利用预读机制。
2. 查询性能稳定且高效
- 时间复杂度稳定 ：B+ 树所有查询都需要从根节点遍历到叶子节点，路径长度相同，时间复杂度稳定为 O(log n)，避免了二叉搜索树退化为链表的极端情况。
- 支持高效范围查询 ：B+ 树的叶子节点构成有序链表，范围查询时只需定位起始点，然后沿链表遍历即可。而 B 树的数据散落在各层，范围查询需要复杂的中序遍历。
3. 更优的存储利用率
- 非叶子节点仅存键值 ：B+ 树的内部节点只存储索引键和子节点指针，不存储实际数据，因此单个节点能容纳更多键，进一步降低树高。
- 数据全存于叶子节点 ：所有数据记录都存储在叶子节点，且通过指针顺序链接，使得全表扫描和范围扫描非常高效（仅需遍历叶子链表）。
4. 适配数据库的读写场景
- 插入和删除效率：B+ 树通过节点分裂/合并保持平衡，且调整主要发生在叶子节点，维护成本相对较低。
- 顺序访问优势 ：数据库常见操作如
ORDER BY、GROUP BY需要顺序访问数据，B+ 树的叶子链表天然支持。
对比其他数据结构
| 结构 | 优点 | 缺点（在数据库场景） |
|---|---|---|
| 哈希表 | 等值查询 O(1) | 无法支持范围查询、排序，内存需求大 |
| 二叉树 | 逻辑简单 | 树高过高导致 I/O 频繁，不适合磁盘存储 |
| B 树 | 节点存储数据，可能减少一次 I/O | 范围查询效率低，节点存储数据导致键数减少，树更高 |
| B+ 树 | 适合磁盘存储、范围查询优、稳定性高 | 等值查询略慢于 B 树（但实际差异微小） |
实际应用中的扩展优势
- 与 InnoDB 引擎深度整合 ：InnoDB 中 B+ 树的叶子节点直接存储数据行 （聚簇索引）或主键指针（二级索引），减少二次查找。
- 锁的粒度优化：B+ 树的叶子链表结构便于实现行级锁和范围锁，支持高并发事务。
总结
MySQL 选择 B+ 树的核心原因是：在兼顾等值查询的同时，极大优化了范围查询和顺序访问，并通过多叉结构最小化磁盘 I/O，适应数据库大数据量、高并发、频繁范围操作的场景 。它是磁盘存储时代在查询性能、存储效率和维护成本之间的最佳平衡之一。