相较于B树而言，B+树的结构又出现了新的变化，一方面节点分为了叶节点和叶子节点两类，这里先有这两个概念即可，后续介绍这两类节点在索引中的作用。B+树中除开节点分为两类外，还有一个最大的变化就是：最下面的一排节点之间，都存在一个单向指针，指向下一个节点所在的位置，这也是B+树对B树的最大改造点：
前面讲过，由于B树不适合于大范围查询操作，因此B+树中多了个指针，当需要做范围查询时，只需要定位第一个节点，然后就可以直接根据各节点之间的指针，获取到对应范围之内的所有节点，也就是只需要发生一次IO，就能够确定所查范围之内的所有数据位置。
OK~，到现在为止，B+树以接近完美的形式解决之前其他数据结构中的所有问题，因此B+Tree正式成为了MySQL默认的索引结构，因此对于MySQL索引为何要选择B+Tree的原因大家应该也懂了，MySQL的设计者在研发时，也绝对是对比了多种数据结构后，逐步推导其缺陷，然后采用更好的数据结构代替，从而最终推导出了B+Tree。
OK~，接下来再说一下前面抛出的一个问题：叶节点和叶子节点在MySQL索引中的作用。
要弄明白这个问题，首先得搞清楚叶节点和叶子节点是什么？其实很简单：
B+Tree上面这些节点则被称为叶节点，在MySQL中不会存储数据，仅存储指向叶子节点的指针，这样做的好处在于能够让一个叶节点中存储更多的元素，从而确保树的高度不会由于数据增长而变得很高。
同时，B+Tree最下面这排节点则被称为叶子节点，这些节点中会存储实际的数据，例如聚簇索引中就直接存储对应的行数据，非聚簇索引中则存储指向主键/聚簇索引的字段值。同时每个叶子节点之间都有一根单向指针指向下一个节点，从而使得最下面的一排叶子节点之间又形成了一个单向链表结构，方便范围取值。
1.5.1、B+Tree结构为何会存在叶节点呢？
其实在之前的数据结构中，从来没有叶节点的这个概念出现，每个节点信息在整棵树结构中只会存储一份，但为什么B+树中会用叶节点，同时冗余一份节点信息呢？因为你从前面的B+Tree结构中，也能明显观测到2、3、4、5节点都会出现了两次。在这里如果想要搞明白为什么要冗余节点，你得想明白一个问题：
能不能将所有的索引数据、表数据全部放入到一个节点中存储呢？这样树的高度永远为1呀，是不是只需要经过一次磁盘IO啊？
其实乍一听似乎有道理，实则是行不通的，因为一次磁盘IO读取的数据量是有限制的，如果将所有的数据全放入到一个节点中存储，那一次磁盘IO只能读取节点的一部分数据，将整个节点读完，本质上就和之前走一次全表没区别了。
理解这个点之后，再来看看抛出的问题：B+Tree为何会有叶节点冗余数据呢？
因为B+Tree的每个节点大小会有限制，所以如果将数据存储在叶节点上，会导致单个树节点存的索引键很少。但如果树的叶节点不存实际的行数据，就代表单个节点可以存更多的索引键，单个节点存的越多也就代表着树的高度会越小，树的高度越小就等价于查询时会发生的磁盘IO次数越少，IO次数越少就相当于数据检索速度会更快，到这里相信大家应该能明白为什么会有叶节点冗余索引键了。
但索引中除开索引键外，也必须要存数据，如果不存数据索引就失去了意义，因此B+tree最下面一排的叶子节点，其中就会存储对应的索引键与行数据/聚簇索引字段值。
一句话来概述，B+Tree的叶节点仅是作为一个“过渡者”的角色，主要是为了提升索引效率的，实际的数据会保存在最下面的叶子节点中，叶节点中仅有一个指针指向罢了。
1.5.2、千万级别的表B+Tree会有多高？
搞清楚B+Tree的一些疑惑后，此时来倒推一个问题，MySQL中一张千万级别的数据表，如果基于自增ID的主键字段建立B+树索引，那此时树会有多高呢？有人或许会认为，虽然B+Tree结构很优异，但千万级别的表至少有1000W条数据，再怎么样应该也有几十、几百的树高吧？但实际上答案会让你大吃一惊。
