哪些缓存页是空闲的呢
接着我们来看下一个问题，当你的数据库运行起来之后，你肯定会不停的执行增删改查的操作，此时就需要不停的从磁盘上读取一个一个的数据页放入Buffer Pool中的对应的缓存页里去，把数据缓存起来，那么以后就可以对这个数据在内存里执行增删改查了。
但是此时在从磁盘上读取数据页放入Buffer Pool中的缓存页的时候，必然涉及到一个问题，那就是哪些缓存页是空闲的？
因为默认情况下磁盘上的数据页和缓存页是一 一对应起来的，都是16KB，一个数据页对应一个缓存页。
所以我们必须要知道Buffer Pool中哪些缓存页是空闲的状态。
所以数据库会为Buffer Pool设计一个free链表，他是一个双向链表数据结构。
这个free链表里，每个节点就是一个空闲的缓存页的描述数据块的地址。
也就是说，只要你一个缓存页是空闲的，那么他的描述数据块就会被放入这个free链表中。
刚开始数据库启动的时候，可能所有的缓存页都是空闲的，因为此时可能是一个空的数据库，一条数据都没有，所以此时所有缓存页的描述数据块，都会被放入这个free链表中。
大家可以看到上面出现了一个free链表，这个free链表里面就是各个缓存页的描述数据块，只要缓存页是空闲的，那么他们对应的描述数据块就会加入到这个free链表中，每个节点都会双向链接自己的前后节点，组成一个双向链表。
除此之外，这个free链表有一个基础节点，他会引用链表的头节点和尾节点，里面还存储了链表中有多少个描述数据块的节点，也就是有多少个空闲的缓存页。
free链表占用多少内存空间？
可能有的人会以为这个描述数据块，在Buffer Pool里有一份，在free链表里也有一份，好像在内存里有两个一模一样的描述数据块，是么？
其实这么想就大错特错了。
这里要给大家讲明白一点，这个free链表，他本身其实就是由Buffer Pool里的描述数据块组成的，你可以认为是每个描述数据块里都有两个指针，一个是free_pre，一个是free_next，分别指向自己的上一个free链表的节点，以及下一个free链表的节点。
通过Buffer Pool中的描述数据块的free_pre和free_next两个指针，就可以把所有的描述数据块串成一个free链表，大家可以自己去思考一下这个问题。上面为了画图需要，所以把描述数据块单独画了一份出来，表示他们之间的指针引用关系。
对于free链表而言，只有一个基础节点是不属于Buffer Pool的，他是40字节大小的一个节点，里面就存放了free链表的头节点的地址，尾节点的地址，还有free链表里当前有多少个节点。
如何将磁盘页读取到BufferPool缓存页？
好了，现在我们可以来解答这一篇文章的最后一个问题了，当你需要把磁盘上的数据页读取到Buffer Pool中的缓存页里去的时候，是怎么做到的？
其实有了free链表之后，这个问题就很简单了。
首先，我们需要从free链表里获取一个描述数据块，然后就可以对应的获取到这个描述数据块对应的空闲缓存页，我们看下图所示。
接着我们就可以把磁盘上的数据页读取到对应的缓存页里去，同时把相关的一些描述数据写入缓存页的描述数据块里去。
比如这个数据页所属的表空间之类的信息，最后把那个描述数据块从free链表里去除就可以了，如下图所示。
如何知道数据页有没有被缓存？
我们在执行增删改查的时候，肯定是先看看这个数据页有没有被缓存，如果没被缓存就走上面的逻辑，从free链表中找到一个空闲的缓存页，从磁盘上读取数据页写入缓存页，写入描述数据，从free链表中移除这个描述数据块。
但是如果数据页已经被缓存了，那么就会直接使用了。
所以其实数据库还会有一个哈希表数据结构，他会用表空间号+数据页号，作为一个key，然后缓存页的地址作为value。
当你要使用一个数据页的时候，通过“表空间号+数据页号”作为key去这个哈希表里查一下，如果没有就读取数据页，如果已经有了，就说明数据页已经被缓存了。
我们看下图，又引入了一个数据页缓存哈希表的结构。
也就是说，每次你读取一个数据页到缓存之后，都会在这个哈希表中写入一个key-value对，key就是表空间号+数据页号，value就是缓存页的地址，那么下次如果你再使用这个数据页，就可以从哈希表里直接读取出来他已经被放入一个缓存页了。
MySQL自适应Hash索引
Hash索引
Hash是一种查找数据非常快的数据结构，在正常情况下这种查找的时间复杂度为O(1)，即一般仅需要一次查找就能定位数据，正常情况是指不存在哈希冲突的情况；而B+树的查找次数，取决于B+树的高度，B+树的高度一般为3、4层，所以一般最少需要3、4次的查询。
InnoDB的Hash索引
InnoDB存储引擎会监控对表上各索引页的查询，如果监控到某个索引页被频繁查询，并诊断后发现如果为这一页的数据创建Hash索引会带来更大的性能提升，则会自动为这一页的数据创建Hash索引，并称之为自适应Hash索引。自适应Hash是通过缓冲池中B+树的页进行构建的，建立速度很快，不需要对整张表的数据都构建Hash索引，所以我们又可以把自适应Hash索引看成是索引的索引。注意一点就是InnoDB只会对热点页构建自适应索引，且是由InnoDB自动创建和删除的，所以不能人为干预是否在一张InnoDB的表中创建Hash索引。
自适应Hash索引
官方有告诉我们每一种存储引擎所支持的索引结构，
我们找寻关于自适应Hash索引的部分，对他总结一下就是：自适应Hash索引特征能使InnoDB在具有适当的工作负载和足够缓冲池内存的系统上执行的更像内存中的数据库的操作，且不会牺牲事务特性或可靠性，MySQL能基于监视到的搜索规则，使用索引键的前缀构建Hash索引，前缀可以是任意长度，并且可能只有b+树中的某些值出现在Hash索引中，Hash索引其实就是对经常访问的索引页进行构建的。
这又说明其实InnoDB是支持Hash索引的，但并不是真正意义上的Hash，而是通过自己的监视情况自动对某些热点索引值构建的内存Hash。
开启和关闭
默认情况下自适应索引是开启状态，毕竟是可以提升性能的嘛，我们也可以通过命令开启和关闭，并可以查看自适应索引的。
开启 默认就是开启的，可以通过命令show variables like ‘innodb_adaptive_hash_index’;查看自适应哈希索引的状态，并可以在命令行通过show engine innodb status\G查看自适应Hash索引的使用信息(AHI的大小，使用情况，每秒使用AHI搜索的情况等等) 关闭 负载较重的情况下，就不太适合开启自适应Hash索引了，因为这样可以避免额外的索引维护带来的开销，可以在启动的时候通过参数–skip-innodb-adaptive-hash-index关闭 。 参考：blog.csdn.net/m0_46761060…
