4.这么做有什么好处呢？用嘟嘟自己画的那张图为例子奥，比如嘟嘟要查6这个数字需要查几次？（1）先查到了5，发现6比5大 ，根据规则，往右侧走到了7。（2）发现6比7小根据规则往左侧走到了6！查完了。用了两步。那么正常按照顺序查询的话，就不一定查多少次了。
5.那么6个随机数字，在我们按照上述规则进行排序之后想要查询一个数字，需要查询多少次？（1）查询第一个数字5需要一步.（2）查询第二层数字3或者7需要2次并且有两种可能，意思是你想查3需要两次，你想查7也得需要两次。（3） 同理，在查询第三层的数字的时候3种可能，并且第三层的任意数字你都需要查三次。所以平均下来就是：
（1+2+2+3+3+3）/（1+2+3）=2.3次平均
相比正常排序的查询（1+2+3+4+5+6）/6=3.5次 查询确实快了一些。原因就是通过比大小的方式，将一些没有必要查询的数字给舍弃了。
6.听说这种树叫做二叉树。而二叉树也有别的画法：
（很明显这种数的查询效率就底下） （1+2+3+4+5+5）/6=3.3次
针对上面那个效率低下的二叉树，就又引入一条规则，进而产生了一种平衡二叉树（AVL Tree）
1.这条规则就是，对于任何一个节点下面的两个子树的高度差都<=1
嘟嘟个人推测这种平衡的机制可以保证搜索效率的最大化（因为嘟嘟时间有限，这个结论是看上面三颗树对比之下的效率感觉的）
2.如果在一棵已经平衡的树上面增加一个数，减少一个数，或者修改一个数，树的平衡就可能被打破了（嘿嘿嘿，嘟嘟想起来文章开头写的，如果某些字段经常发生增删改就不太适合使用索引，因为平衡机制被打破了得话，就得重新耗费资源区重构这种平衡）。
3.如果平衡被打破，需要重构（通过一种叫做旋转的办法保证二叉树的平衡，详细的流程嘟嘟推荐大家看看别的博客），旋转的方式嘟嘟在这里就不再赘述了，意思就是通过位置的调换，保证二叉树的原则就是了。
B-Tree（平衡多路查找树）
1.B-Tree 是针对磁盘等外存储设备设计的一种平衡查找树
2.为什么会出现B-Tree 这种查找机制呢？ 因为InnoDB 存储引擎，InnoDB管理磁盘的最小单位是页（16KB），而磁盘存储数据的最小单位是磁盘块block（远远小于16KB），这就造成了，InnoDB在进行数据读取（比如查找的时候）会将连续的好几个磁盘块读入（老子必须读够16KB！）。这是个硬伤。因为读取也是浪费资源的。而InnoDB你一次读的太多了。
3.针对2中读的太多的问题。如果有一种查找机制可以继续减少查找的时候IO的次数，就会降低资源的浪费。
4.B-Tree诞生了。
下面这张图片能够比较完美的诠释B-Tree的特性
嘟嘟在别的哥哥的博客上扒下来的图片。第一眼看的时候可能是因为天气太热，有点晕乎。但是睡一觉起床以后再看它（MD豁然开朗）
1.首先每一个磁盘块都是一个节点,每个节点都有三个指针两条数据。
2.数据都是以【key,data】的方式存储的。每条指针都存储子节点的地址。两条数据的key值是从小到大排序。
3.于是乎以磁盘块1为例子，就形成了三个区间 {小于17的，17至35的，35以上的}，并分别有不同的指针指向对应的磁盘块。