MySQL InnoDB缓存池

缓存池的作用

缓存表数据与索引数据，把磁盘上的数据加载到缓冲池，避免每次访问都进行磁盘IO，起到加速访问的作用。

为什么不把所有数据放到缓冲池中

凡事都具备两面性，抛开数据易失性不说，访问快速的反面是存储容量小：

• 缓存访问快，但容量小，数据库存储了200G数据，缓存容量可能只有64G;
• 内存访问快，但容量小，买一台笔记本磁盘有2T，内存可能只有16G;

因此，只能把“最热”的数据放到“最近”的地方，以“最大限度”的降低磁盘访问。

什么是预读

磁盘读写，并不是按需读取，而是按页读取，一次至少读一页数据(一般是4K)，如果未来要读取的数据就在页中，就能够省去后续的磁盘IO，提高效率。

预读为什么有效

数据访问，通常都遵循“集中读写”的原则，使用一些数据，大概率会使用附近的数据，这就是所谓的“局部性原理”，它表明提前加载是有效的，确实能够减少磁盘IO。

数据预读跟缓冲池有什么关系

• 磁盘访问按页读取能够提高性能，所以缓冲池一般也是按页缓存数据；
• 预读机制启示了我们，能把一些“可能要访问”的页提前加入缓冲池，避免未来的磁盘IO操作；

如何管理与淘汰缓冲池，使得性能最大化

InnoDB也是用LRU算法来管理缓冲池，但是跟传统的LRU算法不太一样。

传统的LRU算法

把入缓冲池的页放到LRU的头部，作为最近访问的元素，从而最晚被淘汰。这里又分两种情况：

• 页已经在缓冲池里，那就只做“移至”LRU头部的动作，而没有页被淘汰；
• 页不在缓冲池里，除了做“放入”LRU头部的动作，还要做“淘汰”LRU尾部页的动作；

传统的LRU算法十分直观，为什么MySQL不直接使用呢？

这里有两个原因：

1.预读失效

由于预读提前把页放入了缓冲池，但最终MySQL并没有从页中读取数据，称为预读失效。

如何对预读失效进行优化

要优化预读失效，思路是：

• 让预读失败的页，停留在缓冲池LRU里的时间尽可能短；
• 让真正被读取的页，才挪到缓冲池LRU的头部；

具体方法是：

(1)将LRU分为两个部分：

• 新生代(new sublist)
• 老生代(old sublist)

(2)新老生代收尾相连，即：新生代的尾(tail)连接着老生代的头(head);

(3)新页(例如被预读的页)加入缓冲池时，只加入到老生代头部：

• 如果数据真正被读取(预读成功)，才会加入到新生代的头部
• 如果数据没有被读取，则会比新生代里的“热数据页”更早被淘汰出缓冲池

 2.MySQL缓冲池污染

当某一个SQL语句，要批量扫描大量数据时，可能导致把缓冲池的所有页都替换出去，导致大量热数据被换出，MySQL性能急剧下降，这种情况叫缓冲池污染。

例如，有一个数据量较大的用户表，当执行：

select * from user where name like "%shenjian%";

虽然结果集可能只有少量数据，但这类like不能命中索引，必须全表扫描，就需要访问大量的页：

• 把页加到缓冲池(插入老生代头部);
• 从页里读出相关的row(插入新生代头部);
• row里的name字段和字符串shenjian进行比较，如果符合条件，加入到结果集中;
• …直到扫描完所有页中的所有row…

如此一来，所有的数据页都会被加载到新生代的头部，但只会访问一次，真正的热数据被大量换出。

怎么优化这类扫码大量数据导致的缓冲池污染问题

MySQL缓冲池加入了一个“老生代停留时间窗口”的机制：

• 假设T=老生代停留时间窗口；
• 插入老生代头部的页，即使立刻被访问，并不会立刻放入新生代头部；
• 只有满足“被访问”并且“在老生代停留时间”大于T，才会被放入新生代头部；

加入“老生代停留时间窗口”策略后，短时间内被大量加载的页，并不会立刻插入新生代头部，而是优先淘汰那些，短期内仅仅访问了一次的页。而只有在老生代呆的时间足够久，停留时间大于T，才会被插入新生代头部。

上述原理对应InnoDB参数

 (1) 参数：innodb_buffer_pool_size

介绍：配置缓冲池的大小，在内存允许的情况下，DBA往往会建议调大这个参数，越多数据和索引放到内存里，数据库的性能会越好。

(2) 参数：innodb_old_blocks_pct

介绍：老生代占整个LRU链长度的比例，默认是37，即整个LRU中新生代与老生代长度比例是63:37。

画外音：如果把这个参数设为100，就退化为普通LRU了。

(3) 参数：innodb_old_blocks_time

介绍：老生代停留时间窗口，单位是毫秒，默认是1000，即同时满足“被访问”与“在老生代停留时间超过1秒”两个条件，才会被插入到新生代头部。