注意，一次load节点是一次磁盘IO，是非常慢的，但是我们把它load到内存中之后在你内存里随机的找某一个元素是非常快的，跟一次磁盘IO这个时间消耗去比对的话几乎可以忽略不计。
那按这种说法树的高度越小越好，那按这种思路可不可以把一个表的数据都放到一个大的节点上？然后把这个节点一次性load到内存里，我再在内存里一个个去比对不行吗？不是说内存里去比较查找元素是非常的快嘛，跟一次磁盘IO去比对快的多。不可以这样吗？
答案是否定的。
凡事都有个度。你想想，假如我们有几千万数据，在磁盘上面全部放到一个节点上去是不可能的，你的数据表是一行行插入的，存在磁盘上面几百兆甚至几个G，一次性load到内存中合适吗？内存本来就有限，一次性load这么大的数据，而且如果你学过计算机组成原理你也知道，磁盘IO跟内存打交道的单位是4K，一次可能读取4K的数据，可能有时候有一些局部读取的原理可能会取几十K（4的整数倍），取个16K，24K也是可以的 。但是一次交互取这么大是搞不定的，这是计算机组成原理定的，一次磁盘IO取那么多数据，对内存也是非常的浪费，而且这一次磁盘IO也是非常慢的。所以这个节点的大小设置要合适，不能太大也不能太小，mysql对这个节点大小设置的是16K，用下面这个SQL就是可以查到 show clobal status like 'Innodb_page_size' 。
为啥设置16K？为什么不是更大的如16M呢，16K已经足够用了。
MySQL索引选择的不是原生的B-Tree，而是对他进行了改造，得到的是一种叫做B+Tree的数据结构
B+Tree（B-Tree变种）
非叶子节点不存储data，只存储索引（冗余），可以放更多的索引
叶子节点包含所有索引字段
叶子节点用指针连接，提高区间访问的性能
和B-Tree有啥区别？非叶子节点没有数据，数据都挪到叶子节点，叶子节点之间还有指针，非叶子节点之间跟原来一样没有指针。