缓冲池(buffer pool)，此次完全懂了！！！
应用系统分层架构，为了加速数据访问，会把最常访问的数据，放在缓存(cache)里，避免每次都去访问数据库。算法
操做系统，会有缓冲池(buffer pool)机制，避免每次访问磁盘，以加速数据的访问。shell
MySQL做为一个存储系统，一样具备缓冲池(buffer pool)机制，以免每次查询数据都进行磁盘IO。数据库
今天，和你们聊一聊InnoDB的缓冲池。缓存
InnoDB的缓冲池缓存什么？有什么用？
缓存表数据与索引数据，把磁盘上的数据加载到缓冲池，避免每次访问都进行磁盘IO，起到加速访问的做用。架构
速度快，那为啥不把全部数据都放到缓冲池里？
凡事都具有两面性，抛开数据易失性不说，访问快速的反面是存储容量小：
（1）缓存访问快，但容量小，数据库存储了200G数据，缓存容量可能只有64G；
（2）内存访问快，但容量小，买一台笔记本磁盘有2T，内存可能只有16G；
所以，只能把“最热”的数据放到“最近”的地方，以“最大限度”的下降磁盘访问。ide
如何管理与淘汰缓冲池，使得性能最大化呢？
在介绍具体细节以前，先介绍下“预读”的概念。工具
什么是预读？
磁盘读写，并非按需读取，而是按页读取，一次至少读一页数据（通常是4K），若是将来要读取的数据就在页中，就可以省去后续的磁盘IO，提升效率。性能
预读为何有效？
数据访问，一般都遵循“集中读写”的原则，使用一些数据，大几率会使用附近的数据，这就是所谓的“局部性原理”，它代表提早加载是有效的，确实可以减小磁盘IO。优化
按页(4K)读取，和InnoDB的缓冲池设计有啥关系？
（1）磁盘访问按页读取可以提升性能，因此缓冲池通常也是按页缓存数据；
（2）预读机制启示了咱们，能把一些“可能要访问”的页提早加入缓冲池，避免将来的磁盘IO操做；操作系统
InnoDB是以什么算法，来管理这些缓冲页呢？
最容易想到的，就是LRU(Least recently used)。
画外音：memcache，OS都会用LRU来进行页置换管理，但MySQL的玩法并不同。
传统的LRU是如何进行缓冲页管理？
最多见的玩法是，把入缓冲池的页放到LRU的头部，做为最近访问的元素，从而最晚被淘汰。这里又分两种状况：
（1）页已经在缓冲池里，那就只作“移至”LRU头部的动做，而没有页被淘汰；
（2）页不在缓冲池里，除了作“放入”LRU头部的动做，还要作“淘汰”LRU尾部页的动做；
如上图，假如管理缓冲池的LRU长度为10，缓冲了页号为1，3，5…，40，7的页。
假如，接下来要访问的数据在页号为4的页中：
（1）页号为4的页，原本就在缓冲池里；
（2）把页号为4的页，放到LRU的头部便可，没有页被淘汰；
画外音：为了减小数据移动，LRU通常用链表实现。
假如，再接下来要访问的数据在页号为50的页中：
（1）页号为50的页，原来不在缓冲池里；
（2）把页号为50的页，放到LRU头部，同时淘汰尾部页号为7的页；
传统的LRU缓冲池算法十分直观，OS，memcache等不少软件都在用，MySQL为啥这么矫情，不能直接用呢？
这里有两个问题：
（1）预读失效；
（2）缓冲池污染；
什么是预读失效？
因为预读(Read-Ahead)，提早把页放入了缓冲池，但最终MySQL并无从页中读取数据，称为预读失效。
如何对预读失效进行优化？
要优化预读失效，思路是：
（1）让预读失败的页，停留在缓冲池LRU里的时间尽量短；
（2）让真正被读取的页，才挪到缓冲池LRU的头部；
以保证，真正被读取的热数据留在缓冲池里的时间尽量长。
具体方法是：
（1）将LRU分为两个部分：
- 新生代(new sublist)
- 老生代(old sublist)
（2）新老生代收尾相连，即：新生代的尾(tail)链接着老生代的头(head)；
（3）新页（例如被预读的页）加入缓冲池时，只加入到老生代头部： - 若是数据真正被读取（预读成功），才会加入到新生代的头部
- 若是数据没有被读取，则会比新生代里的“热数据页”更早被淘汰出缓冲池
举个例子，整个缓冲池LRU如上图：
（1）整个LRU长度是10；
（2）前70%是新生代；
（3）后30%是老生代；
（4）新老生代首尾相连；
假若有一个页号为50的新页被预读加入缓冲池：
（1）50只会从老生代头部插入，老生代尾部（也是总体尾部）的页会被淘汰掉；
（2）假设50这一页不会被真正读取，即预读失败，它将比新生代的数据更早淘汰出缓冲池；
假如50这一页马上被读取到，例如SQL访问了页内的行row数据：
（1）它会被马上加入到新生代的头部；
（2）新生代的页会被挤到老生代，此时并不会有页面被真正淘汰；
改进版缓冲池LRU可以很好的解决“预读失败”的问题。
画外音：但也不要因噎废食，由于惧怕预读失败而取消预读策略，大部分状况下，局部性原理是成立的，预读是有效的。
新老生代改进版LRU仍然解决不了缓冲池污染的问题。
什么是MySQL缓冲池污染？
当某一个SQL语句，要批量扫描大量数据时，可能致使把缓冲池的全部页都替换出去，致使大量热数据被换出，MySQL性能急剧降低，这种状况叫缓冲池污染。
例如，有一个数据量较大的用户表，当执行：
select * from user where name like "%shenjian%";
虽然结果集可能只有少许数据，但这类like不能命中索引，必须全表扫描，就须要访问大量的页：
（1）把页加到缓冲池（插入老生代头部）；
（2）从页里读出相关的row（插入新生代头部）；
（3）row里的name字段和字符串shenjian进行比较，若是符合条件，加入到结果集中；
（4）…直到扫描完全部页中的全部row…
如此一来，全部的数据页都会被加载到新生代的头部，但只会访问一次，真正的热数据被大量换出。
怎么这类扫码大量数据致使的缓冲池污染问题呢？
MySQL缓冲池加入了一个“老生代停留时间窗口”的机制：
（1）假设T=老生代停留时间窗口；
（2）插入老生代头部的页，即便马上被访问，并不会马上放入新生代头部；
（3）只有知足“被访问”而且“在老生代停留时间”大于T，才会被放入新生代头部；
继续举例，假如批量数据扫描，有51，52，53，54，55等五个页面将要依次被访问。
若是没有“老生代停留时间窗口”的策略，这些批量被访问的页面，会换出大量热数据。
加入“老生代停留时间窗口”策略后，短期内被大量加载的页，并不会马上插入新生代头部，而是优先淘汰那些，短时间内仅仅访问了一次的页。
而只有在老生代呆的时间足够久，停留时间大于T，才会被插入新生代头部。
上述原理，对应InnoDB里哪些参数？
有三个比较重要的参数。
参数：innodb_buffer_pool_size
介绍：配置缓冲池的大小，在内存容许的状况下，DBA每每会建议调大这个参数，越多数据和索引放到内存里，数据库的性能会越好。
参数：innodb_old_blocks_pct
介绍：老生代占整个LRU链长度的比例，默认是37，即整个LRU中新生代与老生代长度比例是63:37。
画外音：若是把这个参数设为100，就退化为普通LRU了。
参数：innodb_old_blocks_time
介绍：老生代停留时间窗口，单位是毫秒，默认是1000，即同时知足“被访问”与“在老生代停留时间超过1秒”两个条件，才会被插入到新生代头部。
总结
（1）缓冲池(buffer pool)是一种常见的下降磁盘访问的机制；
（2）缓冲池一般以页(page)为单位缓存数据；
（3）缓冲池的常见管理算法是LRU，memcache，OS，InnoDB都使用了这种算法；
（4）InnoDB对普通LRU进行了优化：
- 将缓冲池分为老生代和新生代，入缓冲池的页，优先进入老生代，页被访问，才进入新生代，以解决预读失效的问题
- 页被访问，且在老生代停留时间超过配置阈值的，才进入新生代，以解决批量数据访问，大量热数据淘汰的问题
思路，比结论重要。
解决了什么问题，比方案重要。
架构师之路-分享技术思路
相关推荐：
《写一个cache，要掌握哪些技术点》
《6条shell小技巧，让脚本更专业 | 1分钟系列》
《MyISAM与InnoDB的索引差别 | 1分钟系列》
《两个小工具，分析MySQL死锁》
调研：缓冲池是缓存的差异是啥？画外音：长文阅读和转发低，为啥？