InnoDB Purge 和 history list length 过高会影响什么？
简化版
InnoDB 通过 undo log 支持 MVCC。事务提交后，旧版本不能立刻删除，因为可能还有老事务需要读取。Purge 线程负责在安全时清理不再需要的 undo 版本。history list length 过高通常表示旧版本堆积，可能导致 undo 空间膨胀、查询变慢、Buffer Pool 压力增加。常见原因是长事务、慢查询、大批量更新和 purge 跟不上写入。
详细版
MVCC 让读写并发更好，但代价是要保留历史版本。只要有长事务持有很早的 Read View，后续大量更新产生的旧版本就不能清理。这样 history list length 持续上升。
线上表现可能是磁盘占用变大、查询需要沿 undo 链回溯更多版本、purge 线程压力升高，甚至影响整体写入和读取性能。处理时不能只重启数据库，要找到长事务、控制批量更新节奏，并让 purge 有机会追上。
面试中要把它和 MVCC、undo、长事务联系起来。
完整版教学
一、Purge 是什么
Purge 是 InnoDB 清理旧版本的过程。
旧版本来自 undo log。
事务提交后，旧版本不一定马上可删。
如果还有事务可能读到它，就必须保留。
等没有 Read View 需要它时，Purge 才能清理。
二、history list length 表示什么
它大致反映待清理 undo 版本链长度。
数值持续增长说明清理跟不上产生速度。
短时间升高不一定有问题。
长期居高不下才需要警惕。
它常和长事务一起出现。
三、典型原因
| 原因 | 机制 | 影响 |
|---|---|---|
| 长事务 | 持有旧 Read View | 旧版本无法清理 |
| 大批量更新 | 短时间产生大量 undo | purge 压力上升 |
| 慢查询 | 事务持续时间长 | 阻塞清理 |
| 写入高峰 | 产生速度超过清理速度 | history list 增长 |
四、长事务示例
BEGIN;
SELECT * FROM orders WHERE created_at >= '2026-01-01';
-- 很久不提交只要事务不结束，它可能持有旧 Read View。
其他会话不断更新订单时，旧版本就可能堆积。
这不是单条 UPDATE 的问题，而是读事务生命周期问题。
五、它带来的性能问题
undo 表空间可能膨胀。
查询可见性判断成本增加。
Buffer Pool 承受更多历史页压力。
Purge 线程占用后台资源。
极端情况下整体延迟抖动明显。
MVCC 提升并发，但长事务会把“旧版本账单”留给整个系统。
六、治理手段
监控长事务和 history list length。
限制事务持续时间。
批量更新拆小批次提交。
避免在线大事务长时间持有快照。
在低峰期执行重更新任务。
必要时调整 purge 相关参数，但不能替代业务治理。
七、误区和追问
- 误区：事务提交后 undo 立刻删除。 只有没有事务需要旧版本时才能清理。
- 误区：history list length 高只影响磁盘。 它还可能影响查询回溯、缓存和后台线程。
- 误区：重启就能根治。 根因通常是长事务或写入节奏，重启只是临时止血。
- 追问：怎么定位长事务？ 查看事务状态、开始时间、当前 SQL 和持有连接来源。
- 追问：批量更新怎么降低影响？ 分批、短事务、限速、低峰执行，并观察 purge 是否追上。
- 追问：只读事务也会影响 purge 吗？ 会，只要持有旧 Read View 且持续时间长。
八、面试收束
回答时按 MVCC、undo、Purge、长事务、history list length 这条链路讲。
最后落到监控和治理：短事务、分批更新、控制慢查询。