为什么 MySQL 索引必用 B+ 树？深度解析三大设计杀招！

MySQL 选择 B+树 而非 B树 作为索引结构，是由其核心设计目标（高效的磁盘 I/O 操作 和 范围查询优化）决定的。以下是关键原因对比：

核心差异对比表

一、关键设计优势解析

1. 更低的树高 → 减少磁盘 I/O

• B+树：
  非叶子节点不存储数据指针，单节点可容纳更多键值。
  → 在相同数据量下，B+树的高度比 B 树低 30%-50%
  → 查询需要的磁盘 I/O 次数更少（例如：千万级数据仅需 3 次 I/O）

• B树：
  每个节点都存数据指针，节点容量小 → 树更高 → 更多 I/O

2. 范围查询的极致优化

• B+树：
  叶子节点形成双向链表，范围查询（如 WHERE id BETWEEN 100 AND 200）：

  1. 定位到起始位置（ID=100）

  2. 沿链表顺序扫描即可

• B树：
  需反复执行“父节点回溯→子节点查找” → 大量随机 I/O

3. 全表扫描的高效性

• B+树：
  只需遍历叶子节点链表 → 顺序 I/O（磁盘友好）

• B树：
  需层序遍历所有节点 → 随机 I/O + 冗余非叶节点访问

4. 数据稳定性与写入优化

• B+树：
  数据变更仅影响叶子节点，非叶节点作为纯索引层更稳定
  → 减少索引重组概率

• B树：
  数据插入/删除可能导致非叶节点分裂/合并 → 维护开销大

二、性能实测对比（千万级数据表）

💡 范围查询和全表扫描是 OLTP 场景高频操作，B+树优势显著

三、B+树在 InnoDB 中的具体实现

存储结构

• 非叶节点：存储 <键值, 子节点指针>

• 叶子节点：存储 <键值, 数据行指针> + 前后节点指针

查询过程示例（查找 id=25）

1. 从根节点加载（I/O 1）

2. 根据键值定位子节点（如 20<25<30 → 加载页P3）

3. 到达叶子节点，找到 id=25 的数据行位置（I/O 2）

4. 若范围查询：沿链表向右扫描后续节点（无额外 I/O）

四、为什么不用 B 树？关键总结

1. I/O 瓶颈：
   B树的高树深导致更多磁盘寻道（机械硬盘随机 I/O 比顺序 I/O 慢 100 倍）

2. 范围查询缺陷：
   B树无法支持高效的范围扫描（OLTP 场景致命伤）

3. 缓存利用率低：
   B树非叶节点存储数据指针，挤占缓冲池（Buffer Pool）空间
   → 降低热点数据缓存命中率

4. 写入放大问题：
   B树的数据变更波及整棵树 → 加重写负担

📌 结论：B+树通过 ① 非叶节点纯索引化 和 ② 叶子节点链表化，完美适配磁盘存储特性与数据库查询模式，成为关系型数据库索引的黄金标准。