MySQL为什么要使用 B+Tree 作为索引结构？

MySQL为什么要使用 B+Tree 作为索引结构？

基本情况

1. 常规的数据库存储引擎 ，一般都是采用 B 树或者 B+树来实现索引的存储。
2. B树是一种多路平衡树，用这种存储结构来存储大量数据，它的整个高度 会相比二叉树来说 ，会矮很多。
3. 对于数据库来说，所有的数据必然都是存储在磁盘上的 ，而磁盘 IO 的效率实际上是很低的 ，特别是在随机磁盘 IO 的情况下效率更低。
4. 树的高度能够决定磁盘 IO 的次数，磁盘 IO 次数越少，对于性能的提升就越大，这也是为什么采用 B 树作为索引存储结构的原因。
5. MySQL 的 InnoDB 存储引擎里面 ，它用了一种增强的 B 树结构 ，也就是 B+树来作为索引和数据的存储结构。

原因理解

1. B+树的所有数据都存储在叶子节点 ，非叶子节点只存储索引
2. 叶子节点中的数据使用双向链表的方式进行关联
3. B+树非叶子节点不存储数据，所以每一层能够存储的索引数量会增加，意味着 B+树在层高相同的情况下存储的数据量要比 B 树要多 ，使得磁盘 IO 次数更少
4. B+树的所有存储在叶子节点 的数据使用了双向链表来关联 ，所以在查询的时候只需查两个节点进行遍历就行，而 B 树需要获取所有节点 ，所以 B+树在范围查询上效率更高
5. 数据检索方面，由于所有的数据都存储在叶子节点，所以 B+树的 IO 次数会更加稳定一些
6. 因为叶子节点存储所有数据 ，所以 B+树的全局扫描能力更强一些 ，因为它只需要扫描叶子节点，但是 B 树需要遍历整个树
7. 基于 B+树这样一种结构 ，如果采用自增的整型数据作为主键 ，还能更好的避免增加数据的时候 ，带来叶子节点分裂导致的大量运算的问题

结尾

技术方案的选型，更多的是去解决当前场景下的特定问题，并不一定 是说 B+树就是最好的选择，就像 MongoDB 里面采用 B 树结构，本质上来说，其实是关系型数据库和非关系型数据库的差异