结论先行：InnoDB 的读退化不一定来自 I/O——当 undo history list 超过 100 万条时，即使 buffer pool 命中率 99.7%，一次简单的 PK 点查也要遍历 undo 版本链，P99 从 0.3ms 退化到 12ms。根因往往不是 purge 太慢，而是某个长事务把 read view 钉住了，purge 根本不敢清。下面用一次真实事故把机制、定位命令、三个治理方案的取舍讲清。
一、现象：Buffer Pool 命中率 99.7%，点查却从 0.3ms 退化到 12ms
场景：一套订单查询服务，核心表 t_order（1.8 亿行、单表 96GB、InnoDB、MySQL 8.0.32、buffer_pool 64GB），主库承载写、从库承载读。
周五下午 14:00 起，客服后台「按订单号查详情」接口 P99 从常态 0.3ms 逐步爬到 12.4ms，持续了 47 分钟才恢复。期间：
- buffer pool 命中率 99.7%（
Innodb_buffer_pool_read_requestsvsInnodb_buffer_pool_reads），数据全在内存里； - 主库
Innodb_history_list_length从常态 ~300 一路爬到 2,340,000； Innodb_rows_read没有异常飙升（点查就是 1 行）；Innodb_row_lock_waits为 0，没有锁等待；- 从库复制延迟 < 50ms，排除复制问题。
所有"看起来正常"的指标都是绿的，唯独 P99 在涨。 这就是 undo history list 退化的典型特征——它不体现在 I/O 指标里，而是纯 CPU 开销。
二、根因：一条 47 分钟的 ETL 事务把 purge 钉死
MVCC 读路径与 undo 版本链
InnoDB 每行有一个隐藏字段 DB_TRX_ID（最近修改该行的事务 ID）。读操作不是直接返回行，而是：
- 根据当前事务的 read view（包含
m_ids活跃事务列表）判断该行版本是否可见； - 不可见 → 沿
DB_ROLL_PTR指向的 undo log 版本链 逐条回溯，直到找到可见版本； - 回溯过程中每跳一次都要读一条 undo record（即使它在 buffer pool 里，也是一次指针追踪 + 版本比较）。
正常情况下，purge 线程会持续清理"所有活跃事务都不再需要"的旧版本，undo 链长度保持在 1~3 条。
长事务如何卡住 purge
purge 的清理规则是：不能删除任何比"最老活跃事务的 read view"更旧版本。
周五 14:00，一个离线 ETL 任务跑了：
START TRANSACTION;
SELECT * FROM t_order WHERE status = 'PENDING' AND updated_at < '2025-01-01';
-- 应用层逐行处理（1200 万行），耗时 47 分钟
COMMIT;
这条事务持有一个 read view，它的 m_ids 把 14:00 时刻的所有活跃事务 ID 都记下来了。purge 线程发现"还有事务需要 14:00 之前的版本"，于是停止清理。47 分钟里，新写入的事务不断产生新 undo record，history list 从 300 涨到 234 万。
此后每一笔新查询，如果它读到的行恰好被这 47 分钟内的某个事务修改过，就必须沿 undo 链回溯 5~30 条才能找到可见版本。1.8 亿行的热数据区里，被修改过的行占比约 0.4%，但高 QPS（~8000 QPS）下每秒有 32 次命中这种"多版本行"，每次多走 10~30 次 undo 指针追踪——这就是 P99 从 0.3ms 到 12ms 的 CPU 开销来源。
为什么 buffer pool 命中率 99.7% 还是慢？
因为瓶颈不在"读磁盘"，而在CPU 做版本链回溯。undo record 确实在 buffer pool 里（命中率 99.7% 证明了这点），但每条 undo 记录都要：
- 解引用
DB_ROLL_PTR（一次指针追逐，可能跨 cache line）； - 比较
DB_TRX_ID与 read view 的m_ids（一次数组查找，m_ids长度 = 活跃事务数）； - 判断可见性后继续或终止。
30 条 undo 链 × 8000 QPS = 每秒 24 万次额外的指针追踪，在单核上约消耗 12~18μs/次 × 30 = 360~540μs 的 CPU 时间分摊到热路径上。
三、具体做法：定位命令 + 三方案取舍
3.1 实时定位（生产可执行）
-- 1. 看 history list 长度（最核心指标）
SHOW GLOBAL STATUS LIKE 'Innodb_history_list_length';
-- 返回 2,340,000 → 异常（常态 < 10,000）
-- 2. 找"钉子户"事务
SELECT
trx_id, trx_state,
TIMESTAMPDIFF(MINUTE, trx_started, NOW()) AS duration_min,
trx_mysql_thread_id,
LEFT(trx_query, 120) AS query_preview
FROM information_schema.INNODB_TRX
ORDER BY trx_started ASC
LIMIT 10;
-- 找到了那条 47 分钟的 ETL SELECT
-- 3. 看 purge 线程是否在跑
SHOW ENGINE INNODB STATUS\G
-- 关注 "Purge done for trx" 和 "History list length" 行
-- 如果 "Trx Rseg" 部分显示 "History list size: 2340000"，
-- 且 "Modified table rows" 持续增长 → purge 被阻塞
Prometheus 监控规则（建议加到告警）：
- alert: InnoDBHistoryListHigh
expr: innodb_history_list_length > 100000
for: 5m
labels:
severity: warning
annotations:
summary: "InnoDB undo history list 超过 10 万，读操作可能退化"
3.2 方案 A：Kill 长事务（应急，30 秒见效）
-- 确认是 ETL 任务后
KILL 12847; -- trx_mysql_thread_id
Kill 后 read view 释放，purge 立刻恢复清理。我们实测：Kill 后 200 秒内 history list 从 234 万降到 8 万，P99 从 12.4ms 回到 0.4ms。
代价：ETL 任务中断，需要重跑。适合应急，不适合长期。
3.3 方案 B：调大 innodb_purge_threads（缓解，不治本）
# my.cnf
[mysqld]
innodb_purge_threads = 4 # 默认 1
purge 线程从 1 加到 4 后，正常负载下 undo 清理吞吐提升约 3 倍（我们压测：10 万条 undo 清理从 8s 降到 2.7s）。
但关键限制：当 read view 被钉住时，purge 线程再多也不干活——它们的工作前提"可以清理"不成立。所以这个参数只解决"purge 速度不够"的问题，不解决"purge 被阻塞"的问题。
适用场景：无长事务、但写入 QPS 高（>5000 TPS）导致 undo 产生速度 > 单线程 purge 速度。
3.4 方案 C：拆事务（治本，推荐）
把那条 47 分钟的 ETL 改成批次提交：
# 改造前（一条事务 1200 万行）
cursor.execute("SELECT * FROM t_order WHERE status='PENDING' AND updated_at < %s", (cutoff,))
rows = cursor.fetchall() # 1200 万行，47 分钟
# 改造后（每批 5000 行，每批独立事务）
BATCH_SIZE = 5000
while True:
cursor.execute(
"SELECT id, ... FROM t_order WHERE status='PENDING' "
"AND updated_at < %s LIMIT %s", (cutoff, BATCH_SIZE)
)
rows = cursor.fetchall()
if not rows:
break
process(rows) # 业务处理
cursor.execute("UPDATE t_order SET status='DONE' WHERE id IN (%s)" % placeholders, ids)
conn.commit() # ← 关键：每批提交，释放 read view
改造后：单批事务存活时间从 47 分钟降到 1.2 秒，history list 峰值从 234 万降到 ~3,200，P99 稳定在 0.35ms。
代价：失去跨批次的事务原子性（如果第 500 批失败，前 499 批已提交）。对 ETL 场景可接受（幂等重跑）；对金融对账场景需要额外补偿机制。
三方案对比
| 维度 | A: Kill | B: purge_threads=4 | C: 拆事务 | |---|---|---|---| | 见效时间 | 30s | 重启后生效 | 改造上线后 | | 治本程度 | 临时 | 缓解 | 治本 | | 风险 | 任务中断 | 无 | 丧失跨批原子性 | | 适用场景 | 应急 | 高写入无长事务 | 所有长 ETL |
四、踩过的坑与反直觉
-
buffer pool 命中率 99.7% 完全不能排除性能问题。 我们第一反应是"数据都在内存里，为什么还慢"，浪费了 20 分钟排查 I/O。真相是：瓶颈在 CPU 版本回溯，不在磁盘。
-
innodb_purge_threads=4给了虚假安全感。 加到 4 之后跑了一次无长事务的压测，history list 稳定在 2000 以内，以为"修好了"。结果下周 ETL 一跑，history list 照样飙到 180 万——因为问题从来不是 purge 速度，而是 purge 被 read view 阻塞。 -
SHOW ENGINE INNODB STATUS里的 "History list length" 不是实时值。 它是 InnoDB 后台线程上次刷新时的快照，实际值可能比显示的大。更可靠的是SHOW GLOBAL STATUS LIKE 'Innodb_history_list_length'，它读的是原子计数器。 -
从库也会退化，不只是主库。 从库重放 binlog 时也会产生 undo record。如果主库有一条长事务，从库的 history list 同样会涨（因为从库的 read view 被重放事务的 read view 钉住）。我们这次从库的 P99 从 0.5ms 退化到 8ms，比主库的 12ms 还轻——因为从库的写入量是主库的 60%。
-
MySQL 8.0.32 的
innodb_purge_batch_size（默认 300）在高 QPS 下是隐形瓶颈。 它控制每次 purge 批次处理的 undo 条数。我们压测发现把它从 300 调到 3000，在"无长事务 + 高写入"场景下 history list 稳态从 5000 降到 1200。但它对"有长事务"场景毫无帮助。
五、结论与可复用清单
核心认知：InnoDB 的读性能退化有一个"隐形杀手"——undo history list。它不体现在 I/O 指标里，buffer pool 命中率可以是 99%+，锁等待可以是 0，但 CPU 在做大量无用的版本回溯。
可复用清单：
- [ ] 把
Innodb_history_list_length加入 Prometheus 采集，告警阈值 > 100,000 持续 5 分钟； - [ ] ETL / 批处理任务必须分批提交，单事务存活时间控制在 < 30 秒；
- [ ] 高写入场景（>5000 TPS）把
innodb_purge_threads调到 4、innodb_purge_batch_size调到 3000； - [ ] 排查"命中率正常但 P99 高"时，先看 history list 再看 I/O；
- [ ] 对"不能 Kill"的长事务（如大 DDL），用
SET GLOBAL innodb_force_recovery = 0之外的方式：在应用层加max_execution_time或MAX_EXECUTION_TIMEhint 限制查询时长； - [ ] 如果业务必须长事务（如跨表对账），考虑把读流量路由到独立只读实例（不共享 undo 链），代价是多一份存储。
一句话：InnoDB 的 MVCC 是"免费"的——前提是 purge 跑得动。一旦一个事务把 read view 钉住，整个实例的读性能就开始付"版本回溯税"，而且这笔税是 CPU 税，你的 I/O 监控不会告诉你。
参考
- 陈寒山-172《高并发幂等写入的性能税：INSERT ON DUPLICATE KEY UPDATE 在 1800 QPS 下的 P99 翻 15 倍与改造》——同样揭示了 InnoDB 内部机制（锁、版本）对 P99 的隐性放大，但作用点在写路径。