浅析InnoDB purge线程

作者：八怪（高鹏） 中亦科技数据库专家

水平有限，如有错误请谅解。源码版本8.0.21。

---

在处理一个故障的时候怀疑大量的删除数据导致了查询比较慢，但是自己对purge线程的工作流程一直不太清楚，本文不做深入解析，只做工作流程解析，待着如下问题进行：

• del flag记录是否能够及时清理

• 为什么History list length持续不为0，是否代表del flag记录没有清理

• 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，进行无限期等待，直到唤醒
      }

三、克隆最老的read view

这一步没什么好说的，因为清理undo需要根据当前最老的read view来清理，否则可能清理到正在读取需要的undo。