MySQL 写入突然变慢复盘：长事务拖住 purge 导致 undo 历史堆积

线上 MySQL 写入突然变慢时，很多人第一反应是“是不是索引坏了”或“是不是磁盘满了”。但有一类故障不一定表现为单条 SQL 特别慢，而是 InnoDB 内部清理进度被拖住：一个长事务长时间不提交，导致 undo 版本无法及时清理，history list length 持续升高，写入延迟跟着抖动。

这篇按一次故障复盘的方式拆解：先看用户影响和时间线，再定位触发条件、根因、修复动作和防复发措施。

影响面：写入接口 P95 从 80ms 升到 620ms

故障最先从接口监控暴露出来：订单确认和库存扣减的写入 P95 从平时的 80ms 左右升到 620ms，但错误率并没有明显上升。应用日志里没有大量超时，MySQL CPU 也没有打满。

这类现象容易误导排查方向。它不像索引缺失那样有一条明确慢 SQL，也不像磁盘满那样直接报错。更像是数据库内部有一段“清理债务”越积越多，最后让写入和查询都变得不稳定。

时间线：从告警到确认长事务

复盘时先把时间线拉出来，避免只盯着最后一条慢 SQL：

• 10:05：写入接口 P95 开始从 80ms 上升到 240ms。
• 10:12：history list length 从 30k 升到 420k。
• 10:18：应用侧写入 P95 达到 620ms，读接口也出现轻微抖动。
• 10:22：排查到一个持续 25 分钟以上的事务。
• 10:26：结束异常会话后，purge 进度恢复，指标开始回落。

关键证据不是某一秒的高峰，而是 history list length 持续上升，并且它和写入延迟的上升时间基本重合。

触发条件：一个报表查询开启事务后没有结束

先查当前事务列表：

SELECT
  trx_id,
  trx_started,
  trx_state,
  trx_mysql_thread_id,
  trx_query
FROM information_schema.innodb_trx
ORDER BY trx_started
LIMIT 5;

现场看到一个报表会话已经持续二十多分钟，状态仍然是 RUNNING，但业务方以为“查询已经结束”。常见原因是程序开启事务后没有及时提交或回滚，连接又被复用池保持住，导致旧的 read view 一直存在。

再看 InnoDB 状态里的历史链路长度：

SHOW ENGINE INNODB STATUS\G

History list length 842317
Purge done for trx's n:o 

如果这个值持续增长，说明旧版本越来越多，purge 清理跟不上。此时继续压写入，只会让 undo 债务堆得更快。

根因：purge 被旧 read view 拖住

InnoDB 的 MVCC 会保留旧版本，让事务能看到一致性快照。正常情况下，事务结束后，purge 线程会逐步清理不再需要的 undo 版本。

问题出在长事务：只要它的 read view 还活着，一部分旧版本就不能被清理。于是更新、删除产生的新旧版本继续堆积，history list length 变大，后台清理压力、buffer pool 压力和写入抖动都会随之上升。

这次根因可以概括为：

• 报表任务开启事务后没有及时结束。
• 旧 read view 阻塞部分 undo 清理。
• 业务写入继续产生新版本，历史链路持续增长。
• 写入接口受后台清理和存储压力影响，P95 明显升高。

修复动作：结束长事务并观察清理回落

修复要谨慎，先确认异常事务属于可中断任务，再结束对应线程：

KILL 123456;

结束后不要立刻宣布恢复。需要观察至少三类指标：

• history list length 是否停止上升并开始下降。
• 写入接口 P95 是否逐步回到基线。
• 业务报表任务是否有重试、脏状态或半成品输出。

现场恢复过程通常不是瞬间完成。因为已经堆积的历史版本还需要 purge 慢慢清理，所以写入延迟会先停止恶化，再逐步回落。

防复发：把长事务从偶发问题变成可观测指标

最后把这次故障转成可执行的防复发清单：

• 监控 information_schema.innodb_trx 中超过阈值的事务，例如超过 3 分钟告警。
• 监控 history list length 的绝对值和增长速度，不只看 CPU 和连接数。
• 报表、导出、后台扫描任务默认使用只读连接，并设置超时。
• 应用代码用完事务必须提交或回滚，异常分支也要覆盖。
• 连接池归还连接前确认事务状态，避免把未结束事务放回池里。
• 发布前压测包含长查询和批量写入混合场景，验证 purge 是否会被拖住。

总结一下：MySQL 写入变慢不一定是索引问题。看到写入 P95 上升、慢 SQL 不集中、history list length 持续增长时，要优先检查长事务和 purge 状态。修复不是简单调大参数，而是结束拖住 read view 的事务，并把长事务和 undo 堆积纳入日常监控。