关于运用InnoDB存储引擎的表来说，是以页为单位来办理存储空间的，作为内存和磁盘之间换入换出的根本粒度。当咱们将某页从磁盘中加载到内存中，会进行磁盘I/O。而磁盘I/O的开支十分影响全体功能，假如咱们直接从内存中读取相应的页，那岂不是削减了磁盘I/O带来的功能损耗，效率则会提高很多。基于此，缓冲池（
Buffer Pool） 呈现了，那么接下来，咱们就来谈谈InnoDB中的Buffer Pool。
缓冲池（Buffer Pool）
有人会想，既然缓冲池这么好，那咱们将一切数据都存储到缓冲池中不就好了，不不不，缓冲池是操作系统分配的一片接连的内存。而内存相比于磁盘的容量小得多，而且价格昂贵。那么操作系统会给缓冲池分配多少内存呢？
- 默认情况下，缓冲池的巨细为128MB；
当然，假如你的机器的内存容量十分大，能够在装备文件中装备发动选项参数innodb_buffer_pool_size单位是字节，最小不能小于5MB。
缓冲池的内部结构
缓冲池将操作系统分配的这一片接连的内存，划分红若干个巨细默认为16KB的页（缓冲页）【此时还没有真实的磁盘页被缓存到Buffer Pool中】，当咱们从磁盘中换入一个页到缓冲池中，怎么分配位置呢？因而就需求一些操控信息来标识这些缓冲池中的缓冲页，这些操控信息都存放在一个叫操控块的内存区域中，与缓冲页一一对应。操控块的巨细也是固定的。因而在这片接连的内存空间中，难免会产生内存碎片。综上，缓冲池的内部结构如下：
- 缓冲页
- 操控块：页号、缓冲页在缓冲池中的地址、链表节点信息等。
- 内存碎片【若内存分配妥当，内存碎片可有可无】
缓冲池的办理
上面在操控块中提到了链表节点信息，那么链表节点是用来做什么的呢？是为了更好的办理缓冲池中的页。而链表便是用来链接操控块的，因为操控块与缓冲页是一一对应的。
1）闲暇链表
将一切闲暇的缓冲页对应的操控块链接起来，构成的链表。
处理的问题：从磁盘中换入一个页到缓冲池中，怎么区分缓冲池中的哪个页是闲暇的呢？而有了闲暇链表之后，换入一个磁盘页到缓冲池中时，就直接从闲暇链表中获取一个闲暇的缓冲页，并将磁盘页中对应的信息填到缓冲页对应的操控块中，然后将该操控块从闲暇链表中删去即可。
2）更新链表
若修改了缓冲池中的缓冲页的数据，导致其与磁盘中数据不一致，该页称为脏页。将一切脏页对应的操控块链接起来构成更新链表，在将来的某个时刻依据该链表将对应缓存页的数据刷新到磁盘中。
3）LRU链表
缓冲池的巨细是有限的，假如缓存的页超出了缓冲池的巨细，即没有闲暇的缓冲页了，当有新的页要添加到缓冲池中时，采取LRU的战略将旧的缓冲页从缓冲池中移除，然后将新的页添加进来。由于LRU链表触及的内容较多，咱们接下来独自介绍。
LRU链表所蕴含的“哲理”
先提一下预读机制
在I/O上的优化机制，预读顾名思义，会异步地把某些页面加载到缓冲池中，估计很快就会需求这些页面，这些恳求在一个范围内引进一切页面，便是所谓的 局部性原理，目的是削减磁盘I/O。
了解预读机制之前，先回顾一下InnoDB逻辑存储单元：表空间（tablespace）→段（segment ）→区（extent）→页（page）。其间特意提一下区，后边会用到：一个区便是物理位置上接连的64个页，即一个区的巨细是1MB.
预读机制能够细分为以下两种：
- Linear read-ahead（线性预读）：一种基于按次序拜访的缓冲池中的页面来预测或许很快需求哪些页面的技能。经过装备参数innodb_read_ahead_threshold，若次序拜访的某个区的页面超越这个参数的值，会触发异步读恳求来读取下一个区中悉数的页面到缓冲池中。
- Random read-ahead（随机预读）：能够依据缓冲池中已经存在的页面预测何时或许需求页面，而不管这些页面的读取次序怎么。假如在缓冲池中发现同一个区段的13个接连页面，InnoDB会异步宣布一个恳求来预取该区段的剩余页面。经过装备变量innodb_random_read_ahead来操控随机读的。
传统LRU对缓冲页是怎么办理的呢？
利用LRU算法对最近最少运用的缓冲页进行办理，构成对应的链表，便利用于筛选。
当拜访一个页【即最近拜访】
- 该页在缓冲池中，将对应操控块移至LRU链表头部
- 该页不在缓冲池中，筛选尾部最近最少运用的页，从磁盘中加载进来该页并放在LRU链表头部
那么为什么InnoDB不运用这么直观的LRU算法呢？原因如下：
-
预读失效
预读到缓冲池中的页都会放到LRU链表的头部，但其间很多页或许并不会被读取。
-
缓冲池污染
很多运用频率较低的页加载到缓冲池中，会把运用频率较高的页从缓冲池中筛选掉。比如全表扫描
优化后的LRU对缓冲页是怎么办理的呢？
基于上述缺陷，优化后的具体方法将传统LRU链表划分为两部分：热数据区域【年青区】&冷数据区域【老年区】
- 热数据区域【年青区】：运用频率高的缓冲页
- 冷数据区域【老年区】：运用频率低的区域
结构简图如下所示：
如图所示，热数据区域与冷数据区域别离占用不同比例，那么咱们能够经过innodb_old_blocks_pct发动选项来操控冷数据区域所占比例。
改善后的LRU怎么更好的处理预读失效问题呢？
- 某个页在初度加载到缓冲池中时，先筛选掉冷数据区域尾部的操控块（即其对应的页筛选掉），然后新页对应的操控块会先放到冷数据区域的头部。
- 若后续该页不被进行拜访就会渐渐从冷数据区域中被筛选掉，总体不会影响热数据区域拜访频频的缓冲页。
改善后的LRU怎么更好的处理缓冲池污染问题呢？
先说结论，并没有很好的优化这个问题，原因如下【以全表扫描为例】：
- 某个初度拜访的页相同会放到冷数据区域的头部，但后续拜访又会将其放到热数据区域的头部，这样相同会把拜访频率较高的页给挤掉。
那么究竟该怎么处理缓冲池污染问题呢？
- 缓冲池引进了冷数据区域时刻窗口机制，即只需后续拜访该页与榜首拜访该页的时刻距离大于规则的窗口值，就会将该页从冷数据区域移到热数据区域的头部。小于规则的窗口值，就不会进行移动操作。
- 相同，窗口值可经过
innodb_old_blocks_time参数【单位ms】来设置，默认1000ms，而1s会筛选掉大部分像全表扫描这样的操作。比如在一次全表扫描过程中，多次拜访一个页面的时刻距离不会超越1s。
缓冲池VS查询缓存
缓冲池和查询缓存是一个东西吗？→不是
- 缓冲池会尽量将经常运用的数据保存起来，在MySQL进行页面读操作的时分，首先会判断该页面是否在缓冲池中，假如存在就直接读取，假如不存在，就会经过内存或磁盘将页面存放到缓冲池中再进行读取。
- 查询缓存是提前把查询成果缓存起来，这样下次不需求执行就能够直接拿到成果。需求阐明的是，在MySQL中的查询缓存，不是缓存查询计划，而是查询对应的成果。命中条件严苛，而且只需数据表发生变化，查询缓存就会失效，因而命中率低。
