详解MySQL InnoDB存储引擎的内存管理

这篇文章主要介绍了详解MySQL InnoDB存储引擎的内存管理,帮助大家更好的理解和学习使用MySQL数据库,感兴趣的朋友可以了解下

存储引擎之内存管理

在innodb存储引擎中,数据库中的缓冲池是通过lru(latest recent used,最近最少使用)算法来进行管理的,即最频繁使用的页在lru列表的最前段,而最少使用的页在lru列表的尾端,当缓冲池不能存放新读取到的页时,首先释放lru列表尾端的页。

详解MySQL InnoDB存储引擎的内存管理

上面的图中,我使用8个数据页来表示队列,具体作用,先卖个关子。在innodb存储引擎中,缓冲池中页的默认大小是16kb,lru列表中有一个midpoint的位置,新读取到的数据页并不是直接放入到lru列表的首部,而是放入到lru列表的midpoint位置,这个操作称之为midpoint insertion stategy,也叫中间点插入策略。在默认配置下,该位置在lru长度的5/8处,这也就是上面使用8个数据页的作用。下面的图示意了新的数据页的插入过程:

详解MySQL InnoDB存储引擎的内存管理

mitpoint的位置可通过参数innodb_old_blocks_pct控制,如下:

?

1

2

3

4

5

6

7

mysql> show variables like 'innodb_old_blocks_pct';

+———————–+——-+

| variable_name | value |

+———————–+——-+

| innodb_old_blocks_pct | 37 |

+———————–+——-+

row in set (. sec)

从上面的例子看出,结果是37,这个37意味着新读取的页将被插入到大概距离lru列表尾端37%的位置,差不多3/8的位置,在innodb存储引擎中,midpoint之前的页称为new列表,后面的页称之为old列表,new列表中的页是最为活跃的数据。

为什么不直接把数据页放在lru队列的首部?

之所以不把新读取的数据页放在lru队列的首部,是因为某些全表扫描的sql操作可能会将所有的热点数据都刷新出lru队列,导致下一次访问热点数据的时候,必须从磁盘中取相应的数据,从而影响缓冲池的效率。为了解决这个问题,innodb使用另外一个参数来管理lru列表,就是innodb_old_blocks_time,用于表示页读取到midpoint之后,多久才会加入到lru列表的热端。因此当需要执行上述所说的sql操作时,可以通过下面的方法尽可能使lru列表中的热点数据不被刷出。

?

1

2

mysql> set global innodb_old_blocks_time=;

query ok, rows affected (0.00 sec)

这表示在1000s之后,才允许这些数据刷新到lru列表的热端。

如果在实际情况中,数据页活跃的比率不止63%,用户还可以通过设置innodb_old_blocks_pct来减少热点页可能被刷出的概率。

?

1

2

mysql> set global innodb_old_blocks_pct=;

query ok, rows affected (0.00 sec)

当数据库刚启动时,lru的内容是空的,这个时候,所有的数据页都放在free列表中,当需要从缓冲池中分页时,首先从free列表中查找是否有可用的free页,如果存在,则将该页从free页中删除,然后放入到lru的列表中。淘汰掉lru列表末尾的数据页,将该内存空间分配给新的页。这个过程的流程图如下:

详解MySQL InnoDB存储引擎的内存管理

当lru列表中的页从old部分加入到new部分时,称此时发生的操作是page made young,而因为innodb_old_blocks_time的设置而没有从old部分移动到new部分的操作称之为page_not_made young。可以通过show engine innodb status来观察lru列表以及free列表的使用情况和运行状态。

?

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

mysql> show engine innodb status\\g

***

***

———————-

buffer pool and memory

———————-

total large memory allocated

dictionary memory allocated

buffer pool size

free buffers

database pages

old database pages

modified db pages

pending reads

pending writes: lru , flush list , single page

pages made young , not young

0.00 youngs/s, 0.00 non-youngs/s

pages read , created , written

0.00 reads/s, 0.00 creates/s, 0.00 writes/s

no buffer pool page gets since the last printout

pages read ahead 0.00/s, evicted without access 0.00/s, random read ahead 0.00/s

lru len: , unzip_lru len:

i/o sum[]:cur[], unzip sum[]:cur[]

————–

row operations

————–

queries inside innodb, queries in queue

read views open inside innodb

process id=, main thread id=, state: sleeping

number of rows inserted , updated , deleted , read

0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s

—————————-

end of innodb monitor output

============================

row in set (0.00 sec)

从上面的结果可以看到:当前buffer pool size总共有8191个页,每个数据页的大小是16k,总共的大小是8191*16k=128m的缓冲池,其中free buffers表示当前free列表中页的数量。page made young显示了lru列表中页移动到前端的次数,因为该服务器在运行阶段没有改变innodb_old_blocks_time的值,因此not young为0,youngs/s、non_youngs/s表示每秒这两类操作的次数。

innodb存储引擎从1.0.x版本开始支持压缩页的功能,即将原本16kb的数据页压缩成1kb、2kb、4kb和8kb。对于非16kb的页,是通过unzip_lru来管理的,上述命令中的第22行就显示了压缩页和非压缩页的信息。

需要注意的一点是free buffers的值与database pages的值之和不一定等于buffer pool size,因为缓冲池中的页可能还会被分配各自适应哈希索引、锁信息等页,而这部分页并不需要lru算法进行维护。

脏页

在lru列表中的页被修改之后,这个页就称之为“脏页”,即缓冲池中的数据页和磁盘上的数据产生了不一致,缓冲池的数据比较新,这时数据库会通过checkpoint机制将脏页刷新回磁盘,而flush列表中的页也就是脏页列表,脏页既存在于lru列表中,也存在与flush列表中,lru列表用来管理缓冲池中页的可用性,flush列表用来管理将页刷新回磁盘,二者不影响。flush列表也可以通过show engine innodb status来查看,前面的结果列表中的第13行,modified db pages就是当前的脏页数量,用户可以通过元数据表innodb_buffer_page_lru表来查看。

以上就是详解mysql innodb存储引擎的内存管理的详细内容,更多关于innodb 内存管理的资料请关注钦钦技术栈其它相关文章!

原文链接:https://cloud.tencent.com/developer/article/1533579

版权声明:本文(即:原文链接:https://www.qin1qin.com/catagory/8129/)内容由互联网用户自发投稿贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 630367839@qq.com 举报,一经查实,本站将立刻删除。

(0)
上一篇 2022年 8月 2日 9:55:27
下一篇 2022年 8月 2日 9:55:40

软件定制开发公司

相关阅读

发表回复

登录后才能评论
通知:禁止投稿所有关于虚拟货币,币圈类相关文章,发现立即永久封锁账户ID!