为何mysql索引选择b+树做为底层存储结构？

今天是2020年2月3号，毕了业以后的第一个“寒假”，我在院子里晒太阳，闲来无事，写篇博客

这篇文章解决一个问题

mysql 底层为何是用b+树做为存储结构？为何不是二叉树，红黑树，b树？

咱们先构造一个应用场景，咱们有1kw的数据须要存储在一张表里面，那么咱们怎么设计能让查询速度尽量的快

咱们实验的可视化的数据结构皆从如下网站获取，地址：https://www.cs.usfca.edu/~gal...

ok，咱们先来看下二叉树怎么存储这1kw数据，假设我有一张表，这张表里只有一个字段，他是递增的，看看用二叉树是什么情形

因而，咱们看到，在这种状况下二叉树直接退化成了一个链表，咱们若是要找到5这个记录，须要查找5次，n条数据就要查找n次，复杂度O(n), 不知足咱们的需求

咱们再来看看红黑树

咱们看到红黑树有一个自平衡的特性，以牺牲插入性能解决了退化成链表的问题，但随着记录树的增长，树的高度会不断增长，那么，咱们想找到第1kw个数据，依然要查找不少次，对应到mysql上每次读取一个树的节点都须要进行一次io，那么还有没有更好的办法呢？

ok，接下来看看b树

能够明显看到的区别是，每个节点上存储了多个数据，其实逻辑很简单嘛，想保证高度固定，那就横向上想办法，这样的话咱们查找16这条记录，其实只须要通过3次io就能够了

那b+树和b树又有什么区别呢？引用网上的一张图说明一下

具体到mysql上就是

1. 有冗余索引，方便查找
2. 只在叶子节点上存储数据，16k（mysql innodb_page_size的默认大小）的内存能够存下更多数据，下降高度，查询更快
3. 叶子节点增长了双向链表，方便范围查询

因而，咱们就明白了，为何mysql要用b+树做为底层数据结构，1kw的数据，索引应用合理，可能3次或者4次io就能够定位到记录了。