mysql Innodb_buffer_pool的原理

我就是我 2024-04-17 22:37 55阅读 0赞

InnoDB 的 Buffer Pool  
1.innodb存储数据，都是存放在表空间，表空间实际对应着一个或者几个的实际文件。  
2.访问数据的时候，innodb只能以页为单位。  
3.innodb通过Buffer pool 把加载进入内存的页，缓存起来，避免立即释放。

Buffer Pool的简介  
InnoDB的缓冲池缓存什么？有什么用？  
缓存表数据与索引数据，把磁盘上的数据加载到缓冲池，避免每次访问都进行磁盘IO，起到加速访问的作用。速度快，那为啥不把所有数据都放到缓冲池里？  
凡事都具备两面性，抛开数据易失性不说，访问快速的反面是存储容量小：  
（1）缓存访问快，但容量小，数据库存储了200G数据，缓存容量可能只有64G；  
（2）内存访问快，但容量小，买一台笔记本磁盘有2T，内存可能只有16G；因此，只能把“最热”的数据放到“最近”的地方，以“最大限度”的降低磁盘访问。

Buffer Pool内部组成  
1.Buffer Pool中默认的缓存页大小和在磁盘上默认的页大小是一样的，都是16KB  
2.为了管理Pool中的缓存页，Innodb为每一个缓存页创建了一些所谓的控制信息。--控制信息也是写在页上面的。  
3.控制信息包括该页所属的表空间编号、页号、缓存页在Buffer Pool中的地址、链表节点信息、一些锁信息以及LSN信息。  
4.因为每个缓存页对应的控制信息占用的内存大小是相同的，因此从buffer pool中分配一块内存专门记录控制信息--控制块  
5.控制块和缓存页是一一对应的，它们都被存放到 Buffer Pool 中，其中控制块被存放到 Buffer Pool 的前边，缓存页被存放到 Buffer Pool 后边  
6.控制块和缓存页之间是有碎片的--当然如果大小分配合理也有可能没有碎片。  
7.每个控制块大约占用缓存页大小的5%,innodb\_buffer\_pool\_size设置的大小并不包含控制块的大小，也就是说InnoDB在为Buffer Pool向操作系统申请连续的内存空间时，这片连续的内存空间一般会比innodb\_buffer\_pool\_size的值大5%左右。

free链表的管理  
1.Buffer pool中的属于free的控制块单独组成一个链表（方便寻找free页）---free链表（或者说空闲链表）  
2.刚初始化完的buffer pool 就是一个free链表控制块+碎片+缓存页  
3.为了管理好这个free链表，特意为这个链表定义了一个基节点，含着链表的头节点地址，尾节点地址，以及当前链表中节点的数量等信息  
4.基节点的大小不算在bufferpool里面  
5.当从磁盘中加载一个页到Buffer pool中的时候，从free链表中找到控制块，控制块初始化会指向一些空白的缓存页。  
6.当缓存页被使用之后，该控制块就被移除了。当然在移除之前，会把该缓存页的信息填写到控制块上，比如缓存的数据所在  
的表空间，页号之类的。--控制块和缓存页是钉死的，移除控制块的意思就是把该控制块的上一个控制块的free\_next指向该控制块的下一个控制块。  
7.对应的缓存页还是留在原来的位置

缓存页的哈希处理  
1.当我们想要访问某个页中数据的时候，这个时候如果缓存存在就访问缓存，不存在就去磁盘访问  
2.如何检查缓存是否存在？由于表空间和页号是固定的（在生成数据的时候划分好的，持久化到文件）。然后根据这个去hash寻找缓存页  
3.当找不到缓存，再去free链表分配一个页给磁盘加载数据

flush链表的管理  
1.当缓存页被修改了，这就导致数据和磁盘上的页不一样了。  
2.innodb选择在一定的时候进行同步  
3.每个被修改的缓存页最后都会被加入到flush链表。  
4.flush链表和free链表相似 都包含控制块。  
5.在flush链表中的页面肯定在LRU链表中

buffer pool的空间是有限的，那么怎么样进行有效的数据缓存呢？  
mysql引入了LRU（）

传统的LRU是如何进行缓冲页管理？最常见的玩法是，把入缓冲池的页放到LRU的头部，作为最近访问的元素，从而最晚被淘汰。这里又分两种情况：  
（1）页已经在缓冲池里，那就只做“移至”LRU头部的动作，而没有页被淘汰；  
（2）页不在缓冲池里，除了做“放入”LRU头部的动作，还要做“淘汰”LRU尾部页的动作；  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70][]

如上图，假如管理缓冲池的LRU长度为10，缓冲了页号为1，3，5…，40，7的页。假如，接下来要访问的数据在页号为4的页中：  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 1][]

（1）页号为4的页，本来就在缓冲池里；（2）把页号为4的页，放到LRU的头部即可，没有页被淘汰；  
画外音：为了减少数据移动，LRU一般用链表实现。假如，再接下来要访问的数据在页号为50的页中：  
![20190902145207261.png][]

（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）新页（例如被预读的页）加入缓冲池时，只加入到老生代头部：

如果数据真正被读取（预读成功），才会加入到新生代的头部

如果数据没有被读取，则会比新生代里的“热数据页”更早被淘汰出缓冲池

![format_png][]

举个例子，整个缓冲池LRU如上图：

（1）整个LRU长度是10；

（2）前70%是新生代；

（3）后30%是老生代；

（4）新老生代首尾相连；

![format_png 1][]

假如有一个页号为50的新页被预读加入缓冲池：

（1）50只会从老生代头部插入，老生代尾部（也是整体尾部）的页会被淘汰掉；

（2）假设50这一页不会被真正读取，即预读失败，它将比新生代的数据更早淘汰出缓冲池；

![format_png 2][]

假如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，才会被放入新生代头部；

![format_png 3][]

继续举例，假如批量数据扫描，有51，52，53，54，55等五个页面将要依次被访问。

![format_png 4][]

如果没有“老生代停留时间窗口”的策略，这些批量被访问的页面，会换出大量热数据。

![format_png 5][]

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

![format_png 6][]

而只有在老生代呆的时间足够久，停留时间大于T，才会被插入新生代头部。

作者：life丶  
链接：https://www.jianshu.com/p/f9ab1cb24230  
来源：简书  
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

参数：innodb\_buffer\_pool\_size介绍：  
配置缓冲池的大小，在内存允许的情况下，DBA往往会建议调大这个参数，越多数据和索引放到内存里，数据库的性能会越好。  
参数：innodb\_old\_blocks\_pct介绍：  
老生代占整个LRU链长度的比例，默认是37，即整个LRU中新生代与老生代长度比例是63:37。  
画外音：如果把这个参数设为100，就退化为普通LRU了。  
参数：innodb\_old\_blocks\_time介绍：  
老生代停留时间窗口，单位是毫秒，默认是1000，即同时满足“被访问”与“在老生代停留时间超过1秒”两个条件，才会被插入到新生代头部。

https://www.jianshu.com/p/4bf1c77a84d7  --pool的分配  
https://www.jianshu.com/p/f9ab1cb24230  --LRU是如何进行缓冲页管理？

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/17/23589518add5411187cba6b1572890fc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/17/107c3a2f1a544137b3f718bcb19e8ebf.png
[20190902145207261.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/17/1572aabc8fed4aa2959629cdef366970.png
[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xMzU4OTM4Ny1mMWViZTJiOGE0MDU5YmQ0P2ltYWdlTW9ncjIvYXV0by1vcmllbnQvc3RyaXAlN0NpbWFnZVZpZXcyLzIvdy8zODkvZm9ybWF0L3dlYnA?x-oss-process=image/format,png
[format_png 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xMzU4OTM4Ny1iNDViMjM5MGI4ODc0YTE4P2ltYWdlTW9ncjIvYXV0by1vcmllbnQvc3RyaXAlN0NpbWFnZVZpZXcyLzIvdy80MzUvZm9ybWF0L3dlYnA?x-oss-process=image/format,png
[format_png 2]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xMzU4OTM4Ny1kODI0M2EzN2JkMGY5ODU1P2ltYWdlTW9ncjIvYXV0by1vcmllbnQvc3RyaXAlN0NpbWFnZVZpZXcyLzIvdy8zODUvZm9ybWF0L3dlYnA?x-oss-process=image/format,png
[format_png 3]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xMzU4OTM4Ny05ZWNlNDlkMTk0N2VjODhmP2ltYWdlTW9ncjIvYXV0by1vcmllbnQvc3RyaXAlN0NpbWFnZVZpZXcyLzIvdy80MTYvZm9ybWF0L3dlYnA?x-oss-process=image/format,png
[format_png 4]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xMzU4OTM4Ny0wZDllYmMzMmEzZDhlMjg2P2ltYWdlTW9ncjIvYXV0by1vcmllbnQvc3RyaXAlN0NpbWFnZVZpZXcyLzIvdy81NzkvZm9ybWF0L3dlYnA?x-oss-process=image/format,png
[format_png 5]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xMzU4OTM4Ny0xMDI1NDQ2OTY1ODc1YTY3P2ltYWdlTW9ncjIvYXV0by1vcmllbnQvc3RyaXAlN0NpbWFnZVZpZXcyLzIvdy81OTIvZm9ybWF0L3dlYnA?x-oss-process=image/format,png
[format_png 6]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xMzU4OTM4Ny0zYTc2NDcwYmU5ZDUzNDA3P2ltYWdlTW9ncjIvYXV0by1vcmllbnQvc3RyaXAlN0NpbWFnZVZpZXcyLzIvdy81NzgvZm9ybWF0L3dlYnA?x-oss-process=image/format,png