共计 962 个字符，预计需要花费 3 分钟才能阅读完成。
你必定晓得 MySQL 进行 CRUD 是在内存中进行的，也就是在 Buffer Pool 中。而后你也晓得了当内存中没有 MySQL 须要的数据时，MySQL 会从 Disk 中通过 IO 操作将数据读入内存中。读取的单位呢就是：数据页
个别数据页长上面这样
没错，数据页中存储着实在的数据，而且数据页在内存中是以双向联表的形式组织起来的！如下图
而在 B +Tree 的设定中，它要求主键索引时递增的，也就是说如果主键索引时递增的话，那么就要求右侧的数据页中的所有数据均比左侧数据页中的数据大。然而很显著上图并不合乎，因而须要通过页决裂来调整成上面这样。
好，当初你回忆一下，之前你必定有据说过：MySQL 的 B +Tree 聚簇索引，只有叶子节点才存储实在的数据，而非叶子节点中存储的是索引数据，而且叶子节点之间是通过双向链表连接起来
没错，那所有的 B +Tree 的叶子节点就是上图中的数据页，并且它们的确是通过双向链表关联起来的！
咱们接着往下看，如果只看上图由数据页连接起来的双向链表的话，这时如果咱们检索 id= 7 的数据行，那会产生什么？
很显著咱们要从头开始扫描！
那你可能会问：刚才不是说 B +Tree 要求主键是递增的嘛？并且有页决裂机制保障左边的数据页中的所有数据均比它右边的数据页的索引值大。那进行二分查找不行嘛？
答：是的，的确能够在单个数据页中进行二分查找，然而数据页之间的组织关系是链表呀，所以从头开始遍历是防止不了的。
那 MySQL 怎么办的呢？
如下图：MySQL 针对诸多的数据页形象出了一个索引目录
那有了这个索引目录咱们再在诸多的数据页中检索时看起来就容易多了！间接就领有了二分检索的能力！
而且这个所以目录其实也是存在于数据页中的，不同于叶子节点的是，它外面只是存储了索引信息，而叶子节点中存储的是实在数据？
而索引页的诞生也就意味着 B +Tree 的雏形曾经诞生了！
随着用户一直的 select，buffer pool 中的数据页的越来越多，那么索引页中的数据也会水涨船高。当现有的索引体量超过 16KB（一个数据页的容量）时就不得不搞一个新的索引页来存储新的索引信息。这时这颗 B +Tree 就会缓缓变得越来越胖。
那你也晓得 B +Tree 是 B 树的变种，而 B 树其实能够是 2 - 3 树、2-3- 4 数 …. 等等 M 阶树的泛称，当每个节点中能存储的元素达到下限后，树就会长高。
就像下图这样：
