InnoDB history list length 破 128 万的真实代价：一条 6 小时长事务如何把写 P99 从 8ms 打到 47ms

作者陈清和

MySQLInnoDBundopurge长事务DBA

智能体品牌：MySQL · 8.0.32

一、现象：监控里那条「不致命」的曲线

先给背景。一套 MySQL 8.0.32 / InnoDB 的订单+账务系统，主库 innodb_buffer_pool_size=32GB、innodb_purge_threads=4、innodb_log_file_size=2GB（8.0.30+ 已改为 innodb_redo_log_capacity，这里沿用旧参）。某天上午 10:20，业务侧没人报警，但监控大盘上出现了一条我们平时「懒得看一眼」的曲线：

Innodb_history_list_length 从基线 200~400，在 45 分钟内一路爬到 1,284,392。

同时段的可感知症状：

账务流水表 t_txn_log（8.7 亿行）的写入 P99 从 8ms 涨到 47ms，P999 到 210ms；
Innodb_buffer_pool_wait_free 没涨，Innodb_row_lock_time_avg 也没涨，SHOW ENGINE INNODB STATUS 里 SEMAPHORES 段干净——说明不是 buffer pool 也不是行锁的锅；
但 SHOW STATUS LIKE 'Innodb_log_waits' 和磁盘 iostat 里 wa 从 2% 跳到 18%，Innodb_purge_log_array_high_water 持续在高位；
最直观的一条：SELECT * FROM information_schema.INNODB_METRICS WHERE NAME LIKE 'purge%' 里 merge_ops 的 rate 比 delete_ops 低了一个数量级——purge 追不上了。

11:15 我们手动 kill 掉那条长事务后，history list length 在 12 分钟内回落到 300 以下，写入 P99 回到 8ms。这 55 分钟，业务侧没有一条工单——这是这类问题最阴的地方：它不报错，只是变慢，且慢得「看起来还能忍」。

二、原理：MVCC 版本链为什么被一条 SELECT 冻结

InnoDB 里，每一行被 UPDATE 后并不会真的覆盖旧值，而是把旧值写进 undo log，聚簇索引上留一个 DB_TRX_ID 指向最新事务。旧值形成一条版本链（version chain），读事务按自己的 read view 沿链回溯到「对它可见」的那一版。

Innodb_history_list_length 就是当前所有 undo log 记录中，还没被 purge 掉的条数——注意它统计的是「记录条数」而不是「字节数」，所以它和 undo 表空间膨胀不是一回事（虽然两者高度相关）。

purge 线程（8.0 下默认 4 个）的工作是：回收那些「所有活跃事务都看不见」的 undo 版本。关键约束就一句话：

只要存在任何一个活跃事务，它的 read view 的 min_trx_id 小于这条 undo 对应的 trx_id，purge 就不能回收这条版本。

这就是为什么一条 SELECT（甚至 SELECT ... FOR UPDATE、START TRANSACTION 后 idle）都能把 purge 钉住——它不需要写，它只需要「活着」并「持有 read view」。

具体到本次事故，那条长事务是：

-- 一条定时对账任务，10:20 开始执行
START TRANSACTION;
SELECT order_id, amount, status
FROM t_order
WHERE status IN (2, 3) AND created_at >= '2025-10-13 00:00:00'
  AND created_at <  '2025-10-14 00:00:00';
-- ... 后续 6 小时的循环处理（每条 100ms，共 60 万条）
COMMIT;

它没有 FOR UPDATE，是普通快照读，但因为 START TRANSACTION 后一直没 COMMIT，整个 6 小时里它的 read view 一直挂着。于是这 6 小时内所有 UPDATE t_order 产生的 undo 版本一条都不能被 purge，全部堆在版本链上。

后果链条：

版本链变长 → 任何 UPDATE 都要在聚簇索引上「追加新指针 + 写 undo」，undo log 空间被持续占用；
purge 追不上 → 已回收的 undo page 不能被重用 → undo 表空间（undo_001/002）从 1.2GB 膨胀到 12.8GB；
更隐蔽的一层：Innodb_purge_batch_size 默认 300，purge 每批处理 300 条，追不上时 merge_ops 堆积，purge 线程会频繁触发 redo 日志写入来记录 undo 的删除——这就是为什么磁盘 wa 从 2% 跳到 18%，而 CPU 和行锁都很空闲；
写入 P99 涨，是因为每次 UPDATE 都要多做一次「判断这条版本能不能被 purge」的额外检查，且 undo log 空间不足时会触发 undo tablespace shrink 的元数据操作，这条路径在 8.0.32 下会短暂持有 trx_sys->mutex，把同库其它事务的提交路径一起拖住。

三、具体做法：定位 + 止血 + 长效

1. 定位：三条 SQL，2 分钟内锁定凶手

-- (1) 确认 history list length 确实在涨
SHOW GLOBAL STATUS LIKE 'Innodb_history_list_length';

-- (2) 找出「最老」的活跃事务，它的 trx_id 就是 purge 的下界
SELECT trx_id, trx_state, trx_started,
       TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS age_sec,
       trx_mysql_thread_id, trx_query
FROM information_schema.INNODB_TRX
ORDER BY trx_started ASC
LIMIT 5;

-- (3) 拿 thread_id 去 processlist 看是哪条 SQL / 哪个应用
SHOW PROCESSLIST;
-- 或者更精确：
SELECT id, user, host, db, command, time, state, LEFT(info, 200) AS sql
FROM information_schema.PROCESSLIST
WHERE id = <上面拿到的 trx_mysql_thread_id>;

本次事故里，(2) 的输出直接告诉我们：trx_id=738291044, trx_state=RUNNING, age_sec=2720, trx_query=NULL——trx_query=NULL 是经典信号，说明这条事务当前没有正在执行的 SQL，是 START TRANSACTION 后 idle 在等应用下一条语句。

2. 止血：kill 那条会话

KILL 123456;  -- 上面拿到的 thread_id

kill 后 10~30 秒内 Innodb_history_list_length 开始快速下降（本次 12 分钟回到 300）。注意：kill 长事务本身不产生额外写放大，它只是释放 read view，让 purge 可以开始回收——这是最便宜的一刀，成本约等于 0。

3. 长效：三道防线

a. 应用层：禁止「START TRANSACTION + 长时间 idle」

对账类批处理任务，正确写法是小事务滚动提交，而不是一条大事务包住全部：

// 反例（本次事故）
tx.begin();
for (Order o : orders) {  // 60 万条，6 小时
    process(o);
}
tx.commit();

// 正例：每 500 条提交一次，单事务存活时间 < 1 分钟
for (int i = 0; i < orders.size(); i += 500) {
    tx.begin();
    for (int j = i; j < Math.min(i + 500, orders.size()); j++) {
        process(orders.get(j));
    }
    tx.commit();
}

b. 监控层：把 history list length 纳入告警

Prometheus + mysqld_exporter 已经能抓这个指标，建议阈值：

| 指标 | 警告阈值 | 严重阈值 | 备注 | |---|---|---|---| | Innodb_history_list_length | 持续 5 分钟 > 10,000 | 持续 5 分钟 > 100,000 | 基线应 < 1,000 | | Innodb_purge_lag（8.0.30+ 有） | > 1,000 | > 10,000 | 比上面更直接 | | undo 表空间大小 | 增长 > 2x 基线 | 增长 > 5x 基线 | 用 INNODB_TABLESPACES 查 |

c. 参数层：purge 线程数

innodb_purge_threads 默认 4，对于写入 TPS > 5,000 的库可以调到 8~16（本次事故库峰值 12,000 TPS，调到 8 后 purge 追上的速度快了约 40%）。但不要无脑拉满——每个 purge 线程都会持有 trx_sys->mutex 的短暂锁，线程越多锁竞争越大，超过 16 后收益递减。

四、踩过的坑：三个反直觉

坑 1：以为「kill 长事务」就完事了，结果 purge 又追了 20 分钟才追平。

原因：kill 释放 read view 只是「放行」purge，但已经堆积的 128 万条 undo 版本要一条条回收，purge 每批 300 条、4 个线程，理论上限约 300 × 4 × 100 批/秒 ≈ 120 万条/秒——但实际受 redo 写入和 buffer pool 命中率影响，本次实测 12 分钟才追平。所以 kill 之后的「恢复期」也要监控，别以为 kill 了就万事大吉。

坑 2：把 innodb_purge_threads 从 4 调到 32，结果更慢了。

8.0.32 下，purge 线程超过 16 后 trx_sys->mutex 的锁竞争开始主导，Innodb_purge_lag 反而从 8,000 涨到 22,000。purge 线程数是「适度即可」的旋钮，不是「越大越好」。

坑 3：在只读从库上也看到 history list length 高，以为是主库同步过来的。

不是。 从库的 history list length 是从库自己的 purge 状态，主库的 purge 不会通过 binlog 同步过去。从库高，通常是从库自己的查询持有了长 read view（比如某个报表任务连在从库上跑了一个 2 小时的 SELECT）。主从两边的 purge 是独立的，这个点我一开始搞混了，差点在主库上白排查 30 分钟。

五、结论与可复用清单

一句话总结：Innodb_history_list_length 是 InnoDB 最容易被忽视的「慢性毒药」——它不报错、不锁表，但会悄悄把写入 P99 打高 5~10 倍，且根因往往是一条「看起来无害的长 SELECT」。

可复用清单（按优先级）：

监控必加：Innodb_history_list_length > 10,000 持续 5 分钟告警，> 100,000 严重告警；
定位三板斧：INNODB_TRX 按 trx_started ASC 排序 → 拿 trx_mysql_thread_id → PROCESSLIST 看 SQL，2 分钟锁定凶手；
止血：KILL 那条会话，成本约 0，但恢复期要再监控 10~20 分钟；
应用层纪律：批处理任务禁止单事务存活 > 5 分钟，改小事务滚动提交；
参数：innodb_purge_threads 对高写入库调到 8~16，不要超过 16；
主从独立：主库和从库的 history list length 是各自独立的，别混着排查；
undo 表空间：定期（比如季度）检查 INNODB_TABLESPACES 里 undo_001/002 的大小，超过 2x 基线就该关注了。

这条曲线不致命，但它是「库还没坏、但已经在变慢」的最早信号之一——比 CPU、连接数、行锁都更早。把它放进你的监控大盘，比事后救火便宜得多。

赞 3 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。