本文共 1594 字，大约阅读时间需要 5 分钟。

MySQL 数据库优化：purge 线程工作流程解析

1. purge 线程的工作流程概述

purge 线程主要负责清理 InnoDB 存储引擎中的两个关键区域：del flag 记录和 undo 记录（即事务回滚日志）。其工作机制涉及协调线程和多个工作线程，通过特定的规则和参数配置来保证数据库的高效运行。

2. 协调线程的循环检测

协调线程的主要职责是监控和管理 purge 线程的工作状态。其工作流程如下：

• 等待与唤醒机制：

  • 协调线程每隔 10 ms 唤醒一次。
  • 唤醒的条件是检测到新的事务提交或回滚操作。
  • 如果长时间未检测到新事务，协调线程会进入长时间堵塞状态，直到被唤醒。

• 历史长度检测：

  • 如果发现 rseg_history_len 未增加，且小于 5000，协调线程会进入长时间等待状态。
  • 这种情况通常意味着系统处于低事务压力环境。

3. 克隆最老的 read view

为了防止清理过程中影响当前正在读取的数据，purge 线程会在每次清理前克隆最老的 read view。这样可以确保清理操作不会干扰到正在进行的读取操作。

4. 从 purge_queue 中取出 undo segment

purge 线程通过优先队列（priority queue）管理待清理的事务回滚段。具体操作如下：

• 提取最老的事务回滚段。
• 如果当前回滚段的 trx_no 小于等于最旧的 read view 的 low_limit_no，则直接清理该段。
• 否则，继续获取下一个回滚段。

5. 清理规则的判断

在清理过程中，purge 线程会根据以下规则判断是否需要清理当前事务回滚段：

• 如果当前事务回滚段的 trx_no 大于等于最旧的 read view 的 low_limit_no，则需要清理。
• 如果不满足上述条件，则暂停清理，等待下一次检测。

6. 每次清理默认为 300 个 page

purge 线程每次清理默认会处理 300 个页面（由参数 innodb_purge_batch_size 控制）。清理过程会持续执行，直到没有更多需要清理的页面为止。

7. 工作线程处理

一旦协调线程确认需要清理，工作线程会接手具体的清理操作。清理过程包括：

• 解锁相关资源。
• 调用 row_purge 函数进行实际的删除操作。
• 处理可能的并发事务。

8. undo history 清理规则

为了防止 undo history 无限膨胀，purge 线程会根据以下规则进行清理：

• 每 128 次 batch 清理会进行一次 undo history 的清理。
• 清理的频率由参数 innodb_purge_rseg_truncate_frequency 控制。
• 如果小事务频繁且每次修改的页面数量少于 300，则需要等待 128 次才能进行一次清理。
• 如果大事务修改的页面数量多于 300 * 128，则可以直接进行清理。

9. undo history 和 undo 空间清理

undo history 的清理主要包括以下步骤：

如果需要进行 undo tablespace 截断，则需要满足以下条件：

• 参数 innodb_undo_log_truncate 必须开启。
• undo tablespace 的大小超过 innodb_max_undo_log_size。

10. 总结

通过以上流程可以看出，purge 线程的工作机制非常复杂且高效。它通过协调线程和工作线程的协同工作，确保了数据库中的 del flag 记录和 undo 记录能够及时清理，从而保证了数据库的稳定运行。

如果需要进一步了解相关技术，可以通过扫描二维码添加作者的微信，获取更多深入的技术内容。

转载地址：http://htyk.baihongyu.com/