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

2022-05-15 0 1,112
目录
  • 存储引擎之内存管理
  • 为什么不直接把数据页放在LRU队列的首部?
  • 脏页

存储引擎之内存管理

在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控制,如下:

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列表中的热点数据不被刷出。

mysql> set global innodb_old_blocks_time=;
Query OK,  rows affected (0.00 sec)

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

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

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列表的使用情况和运行状态。

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 内存管理的资料请关注NICE源码其它相关文章!

免责声明:
1、本网站所有发布的源码、软件和资料均为收集各大资源网站整理而来;仅限用于学习和研究目的,您必须在下载后的24个小时之内,从您的电脑中彻底删除上述内容。 不得使用于非法商业用途,不得违反国家法律。否则后果自负!

2、本站信息来自网络,版权争议与本站无关。一切关于该资源商业行为与www.niceym.com无关。
如果您喜欢该程序,请支持正版源码、软件,购买注册,得到更好的正版服务。
如有侵犯你版权的,请邮件与我们联系处理(邮箱:skknet@qq.com),本站将立即改正。

NICE源码网 MySql 详解MySQL InnoDB存储引擎的内存管理 https://www.niceym.com/36949.html