OK~，上述内容讲的是操作系统高速缓冲区的知识，在CPU中利用局部性原理，提前将数据从内存先放入L1/L2/L3三级缓冲区中，主要是为了减小CPU寄存器与内存之间的性能差异。
OK~，由于CPU寄存器和内存之间的性能差异太大，所以逐个读数据的形式会导致CPU工作期间的大量时间会处于等待数据状态，所以利用局部性原理将数据“预读”到高速区。而对于MySQL而言，亦是同理，存储数据的磁盘和内存之间的性能差异也是巨大的，因为MySQL也会利用局部性原理，提前“预读”数据。
这是什么意思呢？其实就是指MySQL一次磁盘IO不仅仅只会读取一条表数据，而是会读取多条数据，那到底读多少条数据呢？在InnoDB引擎中，一次默认会读取16KB数据到内存。
1.1.2、全表扫描过程
回到前面分析全表扫描的阶段，由于MySQL中会使用局部性原理的思想，所以对于给出的用户表数据而言，可能只需发生一次磁盘IO就能将前五条数据全部读到内存，然后会在内存中对本次读取的数据逐条判断，看一下每条数据的姓名字段是否为「黑熊」：
- 如果发现不符合SQL条件的行数据，则会将当前这条数据放弃，同时在本次SQL执行过程中会排除掉这条数据，不会对其进行二次读取。
- 如果发现当前的数据符合SQL条件要求，则会将当前数据写入到结果集中，然后继续判断其他数据。
当本次磁盘IO读取到的所有数据全部筛选完成后，紧接着会看一下表中是否还有其他数据，如果还有则继续触发磁盘IO检索数据，如果没有则将内存中的结果集返回。
有人或许会疑惑，为什么这里已经读到了符合条件的数据，还需要继续发生磁盘IO呢？因为表中的字段没有建立唯一索引或唯一约束，因此MySQL不确定是否还有其他同名的数据，所以需要将整个表全部扫描一遍，才能得到最终结论。
好的，到这里就将MySQL全表扫描的过程讲明白了，紧着来看看全表扫描有什么问题呢？
其实按目前的情况来看，似乎不会有太大的问题，因此表中数据不多，一次磁盘IO几乎就能读完。但思考一下，如果当表的数据量变为百万级别、千万级别呢？假设表中一条数据大小为512Bit，一次磁盘IO也只能读32条，假设表中有320w条数据，一次全表就有可能会触发10W次磁盘IO，每次都需要在硬件上让那个盘面转啊转，其过程的开销可想而知.....
因此建立索引的原因就在于此处，为了避免查询时走全表扫描，因此全表扫描的开销会随着数据量增长而越来越大。
1.2、索引为何不选择二叉树？
数据结构与算法，这门学科从诞生到现在，自始至终都让人难以理解，但国外有一个比较厉害的程序员，为了帮助他人更好的理解数据结构，自己搭建了一个数据结构的动画演示平台，里面提供了非常多丰富的数据结构类型，我们在其中能以动画的形式观测数据结构的变化。
回归话题本身，全表扫描由于走的是线性查询，因此数据越多，开销越大，此时先来看看二叉搜索树。
Binary Search Tree二叉搜索树是遵守二分搜索法实现的一种数据结构，咱们先来看看这种数据结构为何不适合用来做索引结构呢？
上图是我提前构建的二叉树，其中存在6个节点，按咱们前面给出的案例，「黑熊」这条数据位于表的第五行，那假设以二叉树作为索引结构，想要定位到第五行数据，需要经过几次磁盘IO呢？来看动图演示效果：
从动画中可以明显看到，想要查到第五条数据，需要经过五次查询，由于树结构在磁盘中存储的位置也不连续，因此无法利用局部性原理读取后续的节点，所以最终需要发生五次磁盘IO才能读取到数据。
- 二叉树不适合作为索引结构的原因：
- ①如果索引的字段值是按顺序增长的，二叉树会转变为链表结构。
