当前位置：首页 > news >正文

深入解析MySQL InnoDB Purge机制

news 2025/9/28 7:00:07

这段文档是关于 MySQL InnoDB 存储引擎中的“Purge 配置” 的详细说明，出自 MySQL 官方手册。它解释了 InnoDB 如何处理数据删除、清理（purge）机制的工作原理，以及相关的性能调优参数。

下面我将用中文为你逐段解读和总结，并结合实际场景帮助你理解其意义。

🔍 一、什么是 Purge（清除）？

原文：

InnoDB does not physically remove a row from the database immediately when you delete it with an SQL statement. A row and its index records are only physically removed when InnoDB discards the undo log record written for the deletion.

解读：

当你执行 DELETE 或 UPDATE 操作时，InnoDB 并不会立即从磁盘上真正删除这行数据，而是：

把旧版本的数据写入 undo log（回滚日志）。
给该记录打上一个“已删除”的标记（delete-marked），但还保留着。
真正的物理删除（即释放空间）要等到 purge 操作 执行后才会发生。

这是为了支持 MVCC（多版本并发控制） 和事务回滚。

✅ 只有当这个旧版本不再被任何正在运行的事务需要时（比如其他事务使用的是可重复读隔离级别），InnoDB 才会通过 purge 线程 把这些“垃圾”数据真正删掉。

📌 这个过程就叫 Purge（清除）。

🔄 二、Purge 是怎么工作的？

原文：

Purge runs on a periodic schedule… processes undo log pages from the history list…

关键概念：History List（历史列表）

当事务提交后，它的 undo log 并不会立刻删除。
这些已提交事务的 undo log 被加入到一个叫做 History List 的链表中。
Purge 线程定期扫描这个列表，处理并最终释放这些 undo log 占用的空间。

🔍 查看方法：

SHOW ENGINE INNODB STATUS;

在输出结果中找 TRANSACTIONS 部分：

------------
TRANSACTIONS
------------
Trx id counter 0 290328385
Purge done for trx's n:o < 0 290315608 undo n:o < 0 17
History list length 20

➡️ History list length 20 表示当前有 20 个已提交但尚未被 purge 清理的事务。

⚠️ 如果这个值持续增长 → 说明 purge 跟不上 DML 操作速度 → 可能导致空间膨胀或性能下降。

⚙️ 三、配置 Purge 线程数：`innodb_purge_threads`

默认值：4

控制后台有多少个线程专门负责执行 purge 操作。
默认 4 个线程可以并行处理不同表的 purge 工作，提高效率。

调整建议：

场景	推荐设置
DML 操作集中在少数几个表上	设置较低（如 1~2）避免多个 purge 线程争抢同一张表的资源
DML 操作分布在大量不同的表上	可以设高一些（如 4~8）提升整体并发清理能力

📌 注意：

最大支持 32 个 purge 线程。
实际使用的线程数由系统自动调节，innodb_purge_threads 是上限。
从 MySQL 8.0.26 开始，如果 purge lag 超过阈值，系统会尝试把工作重新分配给更多线程来加速。

📦 四、配置 Purge 批次大小：`innodb_purge_batch_size`

默认值：300

表示每次 purge 批量处理多少个 undo log 页面。

coordinator thread（协调者线程）会把这个总数平均分给所有活跃的 purge 线程。
- 例如：batch_size=300, purge_threads=4 → 每个线程处理约 75 页。
每处理完 128 次 batch，还会检查是否可以释放 undo log 文件的空间。

💡 提示：

这是一个高级调优参数，大多数情况下保持默认即可。
如果你的实例有大量的大对象（LOB）更新/删除操作，可能需要微调测试效果。

⏳ 五、控制 Purge 延迟：`innodb_max_purge_lag`

默认值：0（表示不限制）

作用：

当 “History list length” 太长（即 purge 落后太多）时，可以通过这个参数让 MySQL 主动放慢 DML 操作的速度，给 purge 时间追上来。

公式变化（重要）：

版本	延迟公式	最小延迟
< MySQL 8.0.14	`(purge_lag / max_purge_lag - 0.5) * 10000`	5000 微秒（5ms）
≥ MySQL 8.0.14	`(purge_lag / max_purge_lag - 0.9995) * 10000`	5 微秒

👉 新公式的优点：更温和，更适合现代高性能系统，防止因 purge lag 瞬间波动造成剧烈延迟。

使用建议：

假设你能容忍最多 100MB 的未清理数据（每条事务平均 100 字节）：

则设置：innodb_max_purge_lag = 1000000 （100万条待清理事务）
当 History list 长度超过这个值，就开始对 INSERT/UPDATE/DELETE 加延迟。

🎯 目标：平衡写入速度与 purge 效率，防止 undo 日志无限增长。

⏱️ 六、限制最大延迟时间：`innodb_max_purge_lag_delay`

单位：微秒（microseconds）

即使设置了 innodb_max_purge_lag，也不能让延迟无限制地增加。

比如你可以设置：

SET GLOBAL innodb_max_purge_lag_delay = 100000; -- 最大延迟 100ms

这样即使 purge lag 非常大，每个 DML 操作最多只被延迟 100ms，防止服务完全卡住。

♻️ 七、Undo 表空间截断（Truncation）

Purge 系统也负责管理 undo 表空间文件的回收。

✅ 总结：关键要点一览表

参数名	默认值	用途	是否推荐调整
`innodb_purge_threads`	4	控制 purge 并行线程数量	✅ 根据负载模式调整
`innodb_purge_batch_size`	300	每批处理多少 undo 页面	❌ 一般不动，仅高级调优
`innodb_max_purge_lag`	0（无限制）	控制 purge 落后程度，超限则加延迟	✅ 写密集型业务建议设非零值
`innodb_max_purge_lag_delay`	0（无上限）	限制单次 DML 延迟上限	✅ 防止极端卡顿
`innodb_purge_rseg_truncate_frequency`	128	控制多久检查一次能否 shrink undo 文件	✅ 若启用 undo 截断可调整

🧩 实际应用建议

场景 1：高频更新/删除的小表（如订单状态变更）

History list 易堆积

建议开启：

SET GLOBAL innodb_max_purge_lag = 1000000;
SET GLOBAL innodb_max_purge_lag_delay = 100000; -- 100ms

场景 2：大批量导入 + 删除临时数据

undo 日志暴涨
建议：
- 启用 undo 自动截断
- 调低 innodb_purge_rseg_truncate_frequency（如设为 10）
- 增加 innodb_purge_threads 到 8

场景 3：长时间运行的只读事务（如报表查询）

导致 MVCC 数据无法清理
结果：History list 持续增长
对策：
- 避免长期不提交的事务
- 监控 SHOW ENGINE INNODB STATUS 中的 history list 长度

📊 监控命令推荐

-- 查看当前 purge 状态和 history list 长度
SHOW ENGINE INNODB STATUS\G-- 查看全局计数器（可用于监控趋势）
SHOW GLOBAL STATUS LIKE 'Innodb_%purge%';-- 查看当前参数设置
SELECT @@innodb_purge_threads,@@innodb_purge_batch_size,@@innodb_max_purge_lag,@@innodb_max_purge_lag_delay,@@innodb_purge_rseg_truncate_frequency;