为什么MySQL InnoDB选择B+树？

首先抛个问题"如何进行sql优化？"

讲到sql优化很多人第一反应："不就是加个索引嘛？！"，的确，加索引确实可以提高sql的查询效率，但为什么在编写sql进行查询的时候还是会出现索引失效导致全表扫描的情况？其实，根本原因在于你没有理解索引的底层设计------B+树数据结构。

什么是B+树？

了解B+树之前，我们先了解一下最简单的二叉树

可以看出二叉树每个节点最多有两个子节点的树结构，子节点分为左孩子和右孩子。它本身只是一种树形结构，不保证有序。

因为不保证插入值的有序性所以查找某个值必须遍历整棵树（O(n)），后面为了保证值有序 的结构来实现高效查找就有了二叉搜索树

如下图所示：

每个节点最多有两个子节点的树结构，子节点分为左孩子和右孩子。

中序遍历 （左→根→右）会得到一个升序序列：30、40、45、50、55、60、99

BST 通过值有序实现了快速查找，但普通BST在极端情况下会退化成链表（如顺序插入 1,2,3,4,5），查找又变成 O(n)。

于是又出现了平衡二叉树（AVL、红黑树），在保持值有序的同时，通过旋转维持树的高度平衡，保证 O(log n) 的操作效率

如果左右子树超过1，那么就会通过旋转保证树的平衡，如图在插入88时正常情况下是插入到70这个节点的右边但是会导致66节点的左右子树高度超过1，所以会旋转一下节点66和节点88作为70的子节点

主要是看某个子树的左边和右边的子节点有没有大于1，如果超过了1，比如66这个节点的子树，左边是0个子节点，右边是2个子节点>1所以就需要找个平衡节点70进行左旋转

问题：每个节点最多两个子节点，树的高度较高。当数据量很大时，树会变得很高，导致磁盘I/O次数多。对于数据库这种以磁盘为存储介质的场景，二叉树不适合，所以就有了下面的B树数据结构。

B树是一种多路平衡查找树，每个节点可以拥有多于两个的子节点。它被设计用于磁盘等外存储设备，降低树的高度，减少磁盘I/O。

如上图所示，每个节点最多有 3个子节点，所以每个节点最多有 2 个关键字

树高度低，磁盘I/O少。节点大小通常设计为一个磁盘页（如16KB），一次I/O读取一个节点，效率高。但是每个节点都存储数据（关键字/索引和值），导致节点能容纳的关键字数量减少，树可能略高。范围查询需要中序遍历，跨层跳转，效率一般。

B+树是B树的变体，专门为数据库和文件系统优化。核心区别：非叶子节点只存储键（索引），不存储数据；所有数据都存储在叶子节点，且叶子节点之间用链表连接。

对比项	二叉树（BST/平衡树）	B树	B+树
子节点数	最多2个	最多m个	最多m个
数据存储位置	每个节点都存数据	每个节点都存数据	仅叶子节点存数据，非叶子只存键
叶子节点链接	无	无	双向链表连接
树的高度	较高（log₂n）	较低（logₘn）	更低（非叶子不存数据，可存更多键）
查找路径	可能提前命中	可能提前命中	必须到叶子
范围查询	中序遍历，效率低	中序遍历，跨层跳转	叶子链表顺序扫描，效率极高
磁盘I/O	高（节点小，树高）	较低	最低（树矮，节点大）
适用场景	内存数据结构	文件系统、部分数据库	数据库索引（MySQL InnoDB）、文件系统
平衡性	需额外平衡（AVL/红黑）	自平衡	自平衡