最近在看高性能MySQL,感觉B—Tree树说的很简洁，所以我找了一下网络上的资料，主要还是熬丙大大的介绍，做一个内容缝合师。 首先我们知道，磁盘IO读取数据耗时起始花在寻道和寻点上面比较多，假设一次IO读取数据是9ms,那么，当数据量过大到百万的时候，那就是9000s了，这很明显不符合要求；
--- 太长不看 -- 靠的是寻道，寻点，拷贝到内存三步；一般来说， 一般来说，寻道就是磁臂移动到指定磁道的时间，一般<=5ms; 寻点，是找到数据存在的那个点，平均是半圈时间，600000/7200/2 = 4.17ms; 拷贝到内存的时间忽略不计。不计算； --- 太长不看 --
所以我们能够做优化的方面主要靠减少IO的读取，或者尽可能多的读取数据；
一方面，在IO读取数据的时候，会把周围的数据也一起读取出来，放入内存缓冲区中，当一页数据被读取到的时候，下次如果读取，会首先看内存缓冲区里面有没有数据，如果有，就从内存缓冲区里面取；
另外一方面，我们可以通过索引的方式，那么就是MySQL中最常用的B-Tree索引；
B-Tree索引，简单来说就是在非叶子节点里面，存储了vlue，key 和数据data，还有就是指向下一个叶子节点的指针，按照从熬丙掘金的图看，起始很简单。
如果我查找一个28的数据，那么首先我在磁盘块一里面能够找到指向p2的指针，然后，通过磁盘块2找到磁盘块8，然后取出叶子节点的数据，这个远比遍历所有数据来的快速,此时io读取了3次，第一次之读根节点磁盘块1，第二次是磁盘块3地区到叶子节点信息，第三次是读取叶子节点的date值；
那么，是不是还可以优化呢？于是就有了B+Tree，两个的区别就是，B+Tree的非叶子节点不存储数据，只在叶子节点存储data，然后我们通过索引确定具体得叶子节点，然后取出叶子节点得数据，而叶子节点，其实存储得也是指针，指向具体data的地址值，于是就可以通过索引获取到数据了；
