背景

mysql purge线程为数据库清理线程，关系到数据的更新。

写在前面

本文主要内容来自微信公众号，原创高鹏。本文将摘录一部分原文。

源码版本8.0.21\

问题


 1. del flag记录是否能够及时清理
 2. 为什么History list length持续不为0，是否代表del flag记录没有清理
 3. purge线程触发的规则是什么

purge线程

一般来讲我们理解的purge线程可以做如下的工作：

清理del flag标签的记录
清理undo的历史版本
如果需要进行undo tablespace截断。
其包含一个协调线程和多个工作线程由如下参数设置：

innodb_purge_threads=4   #默认值
这代表1个协调线程和3个工作线程。协调线程也会充当一个工作线程角色。

协调线程循环检测变化

如下调入：
srv_purge_coordinator_thread
 ->srv_purge_coordinator_suspend
判断如下：
(rseg_history_len <= trx_sys->rseg_history_len) { 
//如果当前history_len大于等于上一次循环的的history_len
      ret =os_event_wait_time_low(slot->event, SRV_PURGE_MAX_TIMEOUT, sig_count); 
//等待10毫秒后进行处理或者等待被唤醒

唤醒的条件是有事务提交或者回滚

    /* Tell server some activity has happened, since the trx
    does changes something. Background utility threads like
    master thread, purge thread or page_cleaner thread might
    have some work to do. */
    srv_active_wake_master_thread();
但是需要注意的是如果长期没有新的事务进行提交，那么可能进入永久堵塞状态而不是每10毫秒醒来，直到唤醒

if (ret == OS_SYNC_TIME_EXCEEDED) { //如果是等待超时
      if (rseg_history_len == trx_sys->rseg_history_len &&
          trx_sys->rseg_history_len < 5000) { //如果上次的history_len和本次history_len相同且小于5000那么需要等待唤醒
        stop = true; //设置为true，进行无限期等待，直到唤醒
      }

摘录到这里，发现全文全是干货
推荐读者移步到原文阅读，以下摘录原文的结论。

del flag在事务提交后，由协调线程判定是否能够进行清理，如果可以清理会分发给工作线程进行清理，这是一个异步的过程，如果修改数据比较多，那么这个过程可能比较慢，并且可以看到purge的相关线程压力较大，但是还算及时。

purge线程总会积压一段时间才会进行History list length的清理，如果是小事务（每次修改的page小于innodb_purge_batch_size的设置），那么需要128个这种小事务才清理一次，如果是大事务那么修改两超过了（innodb_purge_batch_size*innodb_purge_rseg_truncate_frequency）的设置则进行一次清理，但是不管如何这个指标持续不为0是正常。如果较大那么可能意味着要么有大查询，要么purge的各个线程满负荷工作。

purge的协调线程会在每次事务提交的时候醒来，判断是否有需要清理的事务，如果长期没有事务到来那么会第一次等待10ms，超时过后进入长时间的堵塞等待状态。

5.7.26默认参数值
在这里插入图片描述

本文说明，主要技术内容来自互联网技术大佬的分享，还有一些自我的加工(仅仅起到注释说明的作用)。如有相关疑问，请留言，将确认之后，执行侵权必删

InnoDB purge线程

背景

问题

purge线程

猜你喜欢