buffer pool是主存中的一个区域，InnoDB 在访问时缓存表和索引数据。缓冲池允许直接从内存访问频繁使用的数据，这加快了处理速度。在专用服务器上，高达80% 的物理内存通常分配给缓冲池。为了提高大容量读取操作的效率，将缓冲池划分为可能包含多行的页。为了提高缓存管理的效率，缓冲池被实现为页链表; 使用最近使用次数最少(LRU)算法的一个变体，很少使用的数据被老化到缓存之外。
buffer pool LRU
innodb buffer pool LRU在一个新页加入的时候会将最近最少使用的页驱逐出去，并将新页加入到链表中间。中点插入策略将链表看作两个子链表
- 在new sublist的head是最近访问过的
- 在old sublist的tail是最近最少访问过的
在该算法中定义最频繁访问的页在new sublist，old sublist则是访问不频繁的页，等待被淘汰
-
最初访问的页（用户发起的操作或者预读）将会插入到两个sublist的中点。也即new sublist尾部，old sublist头部
-
访问old sublist的页将会使之移动到new sublist的head
如果由于用户发起的操作需要读取该页，则立即进行第一次访问，并使该页更新。如果由于预读操作而读取了该页，则第一次访问不会立即发生，并且可能在驱逐该页之前根本不会发生。
-
当数据库运行时，缓冲池中未被访问的页面会向列表尾部移动，从而“老化”。new sublist中的页面都会随着其他页面的更新而老化。old sublist中的页面也会随着页面在中点插入而老化。最终，未使用的页面到达old sublist的尾部并被驱逐。
默认情况下，查询读取的页面会立即移动到新的子列表中，这意味着它们在缓冲池中停留的时间更长。例如，对于mysqldump操作或不带WHERE子句的SELECT语句执行的表扫描，可能会将大量数据带入缓冲池，并驱逐等量的旧数据，即使新数据不再使用。类似地，由预读后台线程加载且只访问一次的页面被移动到新列表的头部。这些情况可以将经常使用的页面推到旧的子列表中，在那里它们将被删除。
为应对这种情况，innodb在进入new sublist增加了在old sublist的停留时间innodb_old_blocks_time（默认1000ms），也就是在这个时间间隔内，就不会从old移动到new区
预读
在上面的LRU中提到了预读，那么在innodb中预读是如何表现的呢？
- linear: 当一个区有连续56页（56是默认值，可以通过设置innodb_read_ahead_threshold改变。范围是0-64，因为最大就是64页）都被读取，那么该区所有页将会被异步预读到buffer pool
- random: 当一个区随机13个页（13是innodb_random_read_ahead的默认值）都在buffer pool中，那么该区所有页将会被异步预读到buffer pool
innodb LRU在原来LRU的基础上重点是尽快驱逐那些较少使用的数据，为此引入了分段式的链表以及从old到new的时间限制
其实这两个手段很大程度上都是在解决预读所引发的问题，前者是由于预读机制的存在，可能会导致大量并没有实际访问过的数据驱逐了少量实际访问的数据；后者则是因为全表扫描之类情况扫描了全表数据，又因为预读的存在，多读了一次会使得被扫描的数据直接到new sublist
这算得是是一种应对这两种情况的好手段，我在想相比于改良版的k-lru究竟孰强孰弱呢？毕竟只要k设置的合理，这两种情况其实都能避免，只是说k-lru多引入了对访问次数的维护
buffer pool内存管理
在buffer pool中内存管理主要是针对空闲页（也就是如何很快地分配空闲页）以及脏页（也就是如何很快地刷新到持久化储存）
对此，采用了free链表、flush链表分别设计用来管理空闲页和脏页，那样就能很快锁定需要的页，而不需要全部扫描
Ref
- https://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-pool.html
- https://dev.mysql.com/doc/refman/8.0/en/innodb-performance-read_ahead.html
- https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_old_blocks_time
- https://xiaolincoding.com/mysql/buffer_pool/buffer_pool.html
