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尾部页的动作;
如上图,假如管理缓冲池的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,才会被插入新生代头部。
作者: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是如何进行缓冲页管理?