设想一下，每次执行一条修改数据库的SQL，数据库都将修改刷新到磁盘，而这些操作是随机IO，效率是非常低的，想想是不是很可怕。而且MySQL以页（每页大小16KB）的形式管理数据，每次都刷新一页的数据到磁盘，如果修改就刷新一个页，后果更可怕。
上面这张图是存储器的层次结构，磁盘和网络IO最下面两层，我们肯定是不希望经常和他们打交道的。因此，这个时候就需要内存出马了，能不能先缓存一下，统一从缓存刷新到磁盘。
缓存的好处显而易见，如果缓存足够大，我们完全可以把所有的数据都存储在缓存中，但是磁盘的空间通常比缓存要大一个量级，所以我们不可能缓存所有数据，那么问题来了，缓存用完了怎么办？是不是要淘汰？就像家里的衣柜放不下了，你得整理整理，那你是怎么整理呢，把近期不用的先收起来，比如冬天时就把夏天的衣服收起来。这就是传说中的LRU，LRU是Least Recently Used的缩写，即最近最少使用策略。在数据结构与算法中，我们知道LRU一般都是用链表实现的，每次使用到的最新的数据放在链表头部，那些没被用到的就慢慢退回到末尾，等到链表空间不足时，尾部的先被淘汰，缓存就这样不断迭代。是不是还挺简单的。
Talk is easy, show me the money.
But，稍等一下，假设在这样的场景下，MsSQL一次查询执行了全表扫描，或者加载了很多页到内存（参考一条SQL的执行），如果这些页以后再也用不到，把他们放在链表头部，就把那些会被再次使用的页挤走了，导致重新磁盘IO，效率低下，这是不是很尴尬，那么MySQL如何解决呢？
MySQL的解法甚是巧妙，将链表一分为二，而且还不是均分。MySQL把链表分为老年代和新生代（是不是很熟悉），不过新生代是那些经常被使用的，也就是后浪们，老年代是那些很久没被使用的，就是我们这些前浪。他们大小是5/3开，如下图所示：
官方文档地址：https://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-pool.html
新生代和老年代分别有头和尾。新生代头部是经常使用的缓存，而老年代的头部是那些初次加载到内存的页，当我们新读取一个页的时候，不会放到链表的头部，而是链表的中后部，也就是老年代的头部，当他再次被访问时就被提到新生代的头部了。这样就解决了那些一次性读取大量页挤压常用缓冲页的问题了。
是不是有点意思，One more thing，如果一次扫描很多页，并且多次访问，我们知道第一次访问放到新老年代的头部，那么第二次呢，是不是有直接跑到链表的头部了，聪明的MySQL设计者想到了一个办法，他们定义了一个间隔，在这个间隔内的访问都认为是一次访问，这个间隔默认是1s，你也可以修改，不过我认为你也没有必要修改，这样短时间大量访问也不会大量更新缓存。
这就是MySQL buffer pool巧妙的地方，有点奇技淫巧，但都是为了拥抱变化，值得我们学习的设计思想。
