---
水平有限，如有錯誤請諒解。原始碼版本8.0.21。

---
公眾號 MySQL學習

在處理一個故障的時候懷疑大量的刪除資料導致了查詢比較慢，但是自己對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。

```
如下調入：
srv_purge_coordinator_thread
 ->srv_do_purge
  ->trx_purge
操作如下：
trx_sys->mvcc->clone_oldest_view(&purge_sys->view); //克隆老的 read view srv_do_purge
```
###四、從可能需要清理的purge_queue中取出undo segment(簡單理解為事務)

```
調入如下：
srv_purge_coordinator_thread
 ->srv_do_purge
  ->trx_purge
   ->trx_purge_attach_undo_recs
    ->trx_purge_fetch_next_rec
     ->TrxUndoRsegsIterator::set_next
操作如下：
const page_size_t &page_size = purge_sys->rseg_iter->set_next();
```

注意這裡是一個迭代器，迭代的就是purge_sys->purge_queue，這是std::priority_queue實現的優先佇列。具體迭代的程式碼如下：

```
while (!m_purge_sys->purge_queue->empty()) { //如果有事務需要清理
      if (m_trx_undo_rsegs.get_trx_no() == UINT64_UNDEFINED) {
        m_trx_undo_rsegs = purge_sys->purge_queue->top();
      } else if (purge_sys->purge_queue->top().get_trx_no() ==
                 m_trx_undo_rsegs.get_trx_no()) {
        m_trx_undo_rsegs.append(purge_sys->purge_queue->top()); //彈出一個
      } else {
        break;
      }
```

而事務進入purge_queue是在事務commit的時候呼叫trx_serialisation_number_get
```
purge_sys->purge_queue->push(elem);
```

因此到這裡我們知道事務提交的時候可能會喚醒purge協調執行緒進行工作，並且會加入可能需要purge的事務佇列purge_queue中。

###五、判斷是否符合清理規則

```
調入如下：
srv_purge_coordinator_thread
 ->srv_do_purge
  ->trx_purge
   ->trx_purge_attach_undo_recs
    ->trx_purge_fetch_next_rec
判斷如下：
  if (purge_sys->iter.trx_no >= purge_sys->view.low_limit_no()) {
    return (nullptr);
  }
```

這裡就是判斷是否需要清理事務的trx no是否大於了oldest read view的low limit no，如果不滿足則返回為nullptr，如果符合那麼返回需要清理的page數量，並且指向下一個需要清理的undo segment。

###六、每次清理預設為300個page

這個值由引數innodb_purge_batch_size進行控制，預設為300

```
調入如下：
srv_purge_coordinator_thread
 ->srv_do_purge
  ->trx_purge
   ->trx_purge_attach_undo_recs
生效如下：
for (ulint i = 0; n_pages_handled < batch_size; ++i)

```

清理流程會一致持續到沒有塊需要清理為止
```
調入如下：
srv_purge_coordinator_thread
 ->srv_do_purge
判斷如下：
 (!srv_purge_should_exit(n_pages_purged) && n_pages_purged > 0 &&
           purge_sys->state == PURGE_STATE_RUN); 
//清理完成後n_pages_purged > 0 將不會滿足
return (rseg_history_len); //返回 rseg_history_len
```

###七、工作執行緒處理
分發給工作執行緒後進入如下呼叫，進行del flag的清理，沒有仔細的看這部分，呼叫比較複雜。但是可以肯定是其構造row_purge_parse_undo_rec）和刪除過程可能需要大量的迴圈和資料定位（btr_cur_search_to_nth_level）操作。

```
srv_worker_thread
 ->srv_task_execute
  ->que_run_threads
   ->que_run_threads_low
    ->que_thr_step
     ->row_purge_step
      ->row_purge
       ->row_purge_record_func
```

###八、預設每128次batch undo清理會進行undo history清理
這個和引數innodb_purge_rseg_truncate_frequency的設定有關，預設為128，如果滿負荷計算為 ：
- 300(undo log pages)*128(truncate frequency ) = 38,400

38400個undo log pages處理完成後會進行一次undo history清理。

```
根據引數賦值
set_rseg_truncate_frequency(
        static_cast<ulint>(srv_purge_rseg_truncate_frequency));

引數判斷
    ulint rseg_truncate_frequency = ut_min(
        static_cast<ulint>(srv_purge_rseg_truncate_frequency), undo_trunc_freq); //128

n_pages_purged = trx_purge(n_use_threads, srv_purge_batch_size,
                               (++count % rseg_truncate_frequency) == 0);//每128次進行一次清理

判斷是否進入truncate流程
  if (truncate || srv_upgrade_old_undo_found) { //truncate就是根據(++count % rseg_truncate_frequency)計算而來
    trx_purge_truncate();
  }

```

但是需要注意的count是一個static區域性變數，因此每次調入函式會繼續上次的取值繼續計數。如果壓力很小那麼undo可能不能及時清理：

- 小事務
如果都是小事務那麼每個事務修改的undo page數可能達不到300個，那麼必然需要等待128個事務才能進行一次清理。

- 大事務
如果事務比較大，有許多undo page，那麼超過了300*128 那麼就會進行清理。

這不是說del flag記錄不清理，而是說undo history連結串列不清理。因此我們經常看到History list length不為0的情況。

###九、清理undo history和undo空間

這裡簡單記錄其工作的流程。不做深入函式描述（能力有限）

###### 清理undo history
```
調入如下：
srv_purge_coordinator_thread
 ->srv_do_purge
  ->trx_purge
   ->trx_purge_truncate
    ->trx_purge_truncate_history
     ->trx_purge_truncate_rseg_history
```
清理的方式如下：

```
清理的起點：
hdr_addr = trx_purge_get_log_from_hist(
      flst_get_last(rseg_hdr + TRX_RSEG_HISTORY, &mtr));
向上掃描：
 hdr_addr = prev_hdr_addr;
結束條件：
  if (undo_trx_no >= limit->trx_no) { //這裡代表結束了
    /* limit space_id should match the rollback segment
    space id to avoid freeing if the page belongs to a
    different rollback segment for the same trx_no. */
    if (undo_trx_no == limit->trx_no &&
        rseg->space_id == limit->undo_rseg_space) {
      trx_undo_truncate_start(rseg, hdr_addr.page, hdr_addr.boffset,
                              limit->undo_no);
    }

rseg->unlatch();
    mtr_commit(&mtr);

return;
  }
```
值得注意的是這個清理過程不能大於oldest read view的 trx no，否則清理結束。

###### truncate undo流程

```
調入如下：
srv_purge_coordinator_thread
 ->srv_do_purge
  ->trx_purge
   ->trx_purge_truncate
    ->trx_purge_truncate_history
     ->trx_purge_truncate_marked_undo
```     
這之前有一個判定是否清理的過程
```
trx_purge_mark_undo_for_truncate
 ->Tablespace::needs_truncation

```

Tablespace::needs_truncation會判斷是否進行undo truncate，這裡涉及到兩個引數

- 引數innodb_undo_log_truncate的作用
```
  if (!srv_undo_log_truncate || m_rsegs == nullptr || m_rsegs->is_empty() ||
      m_rsegs->is_init()) {
    m_rsegs->s_unlock();
    return (false); //如果沒有開啟undo truncate則不進行清理
  }
```
- 引數innodb_max_undo_log_size的作用
```
page_no_t trunc_size = ut_max(
      static_cast<page_no_t>(srv_max_undo_tablespace_size / srv_page_size),
      static_cast<page_no_t>(SRV_UNDO_TABLESPACE_SIZE_IN_PAGES)); //10MB

if (fil_space_get_size(id()) > trunc_size) { //如果undo tablespace大小大於了innodb_max_undo_log_size
    return (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的各個執行緒滿負荷工作。如下,9281為一個purge的工作執行緒:

![image.png](https://upload-images.jianshu.io/upload_images/7398834-e4da8ea32390b6ce.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

並且purge執行緒狀態處於running狀態
![image.png](https://upload-images.jianshu.io/upload_images/7398834-770f320bfa7e1d2b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

- purge的協調執行緒會在每次事務提交的時候醒來，判斷是否有需要清理的事務，如果長期沒有事務到來那麼會第一次等待10ms，超時過後進入長時間的堵塞等待狀態。

###十一、相關斷點

```
(gdb) info b
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x00000000035a5f75 in main(int, char**) at /opt/mysql/mysql-8.0.21/sql/main.cc:25
        breakpoint already hit 1 time
5       breakpoint     keep y   0x0000000005030e9e in row_purge_record_func(purge_node_t*, trx_undo_rec_t*, que_thr_t const*, bool, THD*) 
                                                   at /opt/mysql/mysql-8.0.21/storage/innobase/row/row0purge.cc:1082
7       breakpoint     keep y   0x00000000050d5bb0 in trx_purge_fetch_next_rec(trx_id_t*, roll_ptr_t*, ulint*, mem_heap_t*) 
                                                   at /opt/mysql/mysql-8.0.21/storage/innobase/trx/trx0purge.cc:2022
        breakpoint already hit 2 times (這個斷點比較重要如果沒有需要清理的這裡不會進入)
```

高壓下的工作執行緒堆疊：
```
(gdb) bt
#0  ha_chain_get_first (table=0x7fff642eec10, fold=14919132254711319759) at /opt/mysql/mysql-8.0.21/storage/innobase/include/ha0ha.ic:95
#1  0x000000000519e235 in ha_search_with_data (table=0x7fff642eec10, fold=14919132254711319759, data=0x7fff338fa218 "") at /opt/mysql/mysql-8.0.21/storage/innobase/include/ha0ha.ic:173
#2  0x000000000519e2da in ha_search_and_delete_if_found (table=0x7fff642eec10, fold=14919132254711319759, data=0x7fff338fa218 "")
    at /opt/mysql/mysql-8.0.21/storage/innobase/include/ha0ha.ic:200
#3  0x00000000051a567a in btr_search_update_hash_on_delete (cursor=0x7fff668555c0) at /opt/mysql/mysql-8.0.21/storage/innobase/btr/btr0sea.cc:1724
#4  0x00000000051948bb in btr_cur_pessimistic_delete (err=0x7ffed17f10ec, has_reserved_extents=0, cursor=0x7fff668555c0, flags=0, rollback=false, trx_id=38031, undo_no=0, rec_type=14, 
    mtr=0x7ffed17f1420, pcur=0x7fff668555c0) at /opt/mysql/mysql-8.0.21/storage/innobase/btr/btr0cur.cc:4833
#5  0x000000000502ed6e in row_purge_remove_clust_if_poss_low (node=0x7fff66855510, mode=65569) at /opt/mysql/mysql-8.0.21/storage/innobase/row/row0purge.cc:204
#6  0x000000000502ee8c in row_purge_remove_clust_if_poss (node=0x7fff66855510) at /opt/mysql/mysql-8.0.21/storage/innobase/row/row0purge.cc:245
#7  0x000000000502feb4 in row_purge_del_mark (node=0x7fff66855510) at /opt/mysql/mysql-8.0.21/storage/innobase/row/row0purge.cc:683
#8  0x0000000005030f92 in row_purge_record_func (node=0x7fff66855510, undo_rec=0x7ffefc431418 "$&N", thr=0x7fff66855328, updated_extern=false, thd=0x7fff0c000a40)
    at /opt/mysql/mysql-8.0.21/storage/innobase/row/row0purge.cc:1094
#9  0x0000000005031333 in row_purge (node=0x7fff66855510, undo_rec=0x7ffefc431418 "$&N", thr=0x7fff66855328) at /opt/mysql/mysql-8.0.21/storage/innobase/row/row0purge.cc:1168
#10 0x000000000503164c in row_purge_step (thr=0x7fff66855328) at /opt/mysql/mysql-8.0.21/storage/innobase/row/row0purge.cc:1240
#11 0x0000000004f97868 in que_thr_step (thr=0x7fff66855328) at /opt/mysql/mysql-8.0.21/storage/innobase/que/que0que.cc:915
#12 0x0000000004f97a1b in que_run_threads_low (thr=0x7fff66855328) at /opt/mysql/mysql-8.0.21/storage/innobase/que/que0que.cc:966
#13 0x0000000004f97c52 in que_run_threads (thr=0x7fff66855328) at /opt/mysql/mysql-8.0.21/storage/innobase/que/que0que.cc:1001
#14 0x0000000005082f83 in srv_task_execute () at /opt/mysql/mysql-8.0.21/storage/innobase/srv/srv0srv.cc:2888
#15 0x000000000508311a in srv_worker_thread () at /opt/mysql/mysql-8.0.21/storage/innobase/srv/srv0srv.cc:2927
#16 0x0000000004f18ea3 in std::_Bind<void>::__call<void>(std::tuple<>&&, std::_Index_tuple<>) (this=0x7ffed17f1c50, 
    __args=<unknown type="" in="" cu="" die="">) at /usr/local/include/c++/5.5.0/functional:1074
#17 0x0000000004f18e4a in std::_Bind<void>::operator()() (this=0x7ffed17f1c50) at /usr/local/include/c++/5.5.0/functional:1133
#18 0x0000000004f18d8a in Runnable::operator()<void>(void (*&&)()) (this=0xa814df0, f=<unknown type="" in="" cu="" die="">)
    at /opt/mysql/mysql-8.0.21/storage/innobase/include/os0thread-create.h:101
#19 0x0000000004f18ccf in std::_Bind_simple<runnable>::_M_invoke<0ul>(std::_Index_tuple<0ul>) (this=0xa814de8) at /usr/local/include/c++/5.5.0/functional:1531
#20 0x0000000004f18be9 in std::_Bind_simple<runnable>::operator()() (this=0xa814de8) at /usr/local/include/c++/5.5.0/functional:1520
#21 0x0000000004f18b88 in std::thread::_Impl<:_bind_simple> >::_M_run() (this=0xa814dd0) at /usr/local/include/c++/5.5.0/thread:115
#22 0x00007ffff66d6880 in std::execute_native_thread_routine (__p=<optimized out="">) at ../../../../../libstdc++-v3/src/c++11/thread.cc:84
#23 0x00007ffff7bc6ea5 in start_thread () from /lib64/libpthread.so.0
#24 0x00007ffff5e388dd in clone () from /lib64/libc.so.6
```</optimized></:_bind_simple></runnable></runnable></unknown></void></void></unknown></void></void></page_no_t></page_no_t></ulint></ulint>

MySQL：Innodb purge執行緒略解

相關文章