这是一个3叉（只是举例，真实会有很多叉）的BTree结构图，每一个方框块我们称之为一个磁盘块或者叫做一个block块，这是操作系统一次IO往内存中读的内容，一个块对应四个扇区，紫色代表的是磁盘块中的数据key，黄色代表的是数据data，蓝色代表的是指针p，指向下一个磁盘块的位置。
来模拟下查找key为29的data的过程：
1、根据根结点指针读取文件目录的根磁盘块1。【磁盘IO操作1次】
2、磁盘块1存储17，35和三个指针数据。我们发现17<29<35，因此我们找到指针p2。
3、根据p2指针，我们定位并读取磁盘块3。【磁盘IO操作2次】
4、磁盘块3存储26，30和三个指针数据。我们发现26<29<30，因此我们找到指针p2。
5、根据p2指针，我们定位并读取磁盘块8。【磁盘IO操作3次】
6、磁盘块8中存储28，29。我们找到29，获取29所对应的数据data。
但是有没有什么可优化的地方呢？
我们从图上可以看到，每个节点中不仅包含数据的key值，还有data值。而每一个页的存储空间是有限的，如果data数据较大时将会导致每个节点（即一个页）能存储的key的数量很小，当存储的数据量很大时同样会导致B-Tree的深度较大，增大查询时的磁盘I/O次数，进而影响查询效率。
B+Tree索引
B+Tree是在B-Tree基础上的一种优化，使其更适合实现外存储索引结构。在B+Tree中，所有数据记录节点都是按照键值大小顺序存放在同一层的叶子节点上，而非叶子节点上只存储key值信息，这样可以大大加大每个节点存储的key值数量，降低B+Tree的高度。
B+Tree相对于B-Tree有几点不同：
非叶子节点只存储键值信息， 数据记录都存放在叶子节点中， 将上一节中的B-Tree优化，由于B+Tree的非叶子节点只存储键值信息，所以B+Tree的高度可以被压缩到特别的低。
具体的数据如下：
我们只需要进行三次的IO操作就可以从10亿条数据中找到我们想要的数据，比起最开始的百万数据9000秒不知道好了多少个华莱士了。
而且在B+Tree上通常有两个头指针，一个指向根节点，另一个指向关键字最小的叶子节点，而且所有叶子节点（即数据节点）之间是一种链式环结构。所以我们除了可以对B+Tree进行主键的范围查找和分页查找，还可以从根节点开始，进行随机查找。
数据库中的B+Tree索引可以分为聚集索引（clustered index）和辅助索引（secondary index）。
上面的B+Tree示例图在数据库中的实现即为聚集索引，聚集索引的B+Tree中的叶子节点存放的是整张表的行记录数据，辅助索引与聚集索引的区别在于辅助索引的叶子节点并不包含行记录的全部数据，而是存储相应行数据的聚集索引键，即主键。
当通过辅助索引来查询数据时，InnoDB存储引擎会遍历辅助索引找到主键，然后再通过主键在聚集索引中找到完整的行记录数据。
不过，虽然索引可以加快查询速度，提高 MySQL 的处理性能，但是过多地使用索引也会造成以下弊端：
索引只是提高效率的一个因素，因此在建立索引的时候应该遵循以下原则：
现在大家知道索引为啥能这么快了吧，其实就是一句话，通过索引的结构最大化的减少数据库的IO次数，毕竟，一次IO的时间真的是太久了。。。
总结
就面试而言很多知识其实我们可以很容易就掌握了，但是要以学习为目的，你会发现很多东西我们得深入到计算机基础上才能发现其中奥秘，很多人问我怎么记住这么多东西，其实学习本身就是一个很无奈的东西，既然我们不能不学那为啥不好好学？去学会享受呢？最近我也在恶补基础，后面我会开始更新计算机基础和网络相关的知识的。
我是敖丙，你知道的越多，你不知道的越多，我们下期见！
人才们的 【三连】 就是敖丙创作的最大动力，如果本篇博客有任何错误和建议，欢迎人才们留言！