mysql 5.7 中无法通过 undo log 主动恢复未提交事务，它仅支持自动回滚；需通过查询 innodb_trx 和 processlist 定位长事务，history list length 持续增长表明存在长期未释放的读视图，根本解决方法是控制事务生命周期而非调参。
MySQL 5.7 中无法通过 undo log 主动“恢复”未提交事务——它只负责回滚，不提供手动回放或提取前镜像的能力。 你看到的“未提交事务”，在崩溃重启后会被 InnoDB 自动回滚；而如果实例仍在运行，那些事务只是卡住没提交，此时你要做的是定位、干预或终止，而不是“恢复”它们。
如何查出阻塞 purge 的长事务
undo 膨胀的根本原因是存在长时间未结束的事务（哪怕只是 START TRANSACTION 后什么都没干），它锁住了最老的 read view，导致 purge 线程不敢清理后续所有 undo 记录。
- 执行
SELECT * FROM information_schema.INNODB_TRX\G，重点关注trx_started字段：时间早于 1 小时的都值得怀疑 - 配合
SHOW ENGINE INNODB STATUS\G，在TRANSACTIONS部分找ACTIVE状态且trx_mysql_thread_id对应的连接 - 用
SELECT * FROM information_schema.PROCESSLIST WHERE ID = [thread_id]查看该连接当前执行的 SQL 和状态（比如Sleep或Query卡在某个语句）
History list length 持续增长说明什么
History list length 是 SHOW ENGINE INNODB STATUS\G 输出中 “LOG” 小节里的关键指标，它代表当前等待被 purge 的 undo record 总数。这个值不是越大越危险，而是“长期不下降”才危险。
- 正常业务下，该值在几百到几千之间波动是健康的
- 若持续 > 50000 且缓慢爬升，基本可断定有事务或读视图长期未释放
- 注意：该值不会因为 kill 掉一个长事务立刻归零，purge 是异步的，可能需要几十秒到几分钟回落
- 检查
innodb_purge_threads是否为 1（5.7 默认值），建议设为4加速清理
为什么不能直接删 undo_001 这类文件
undo 文件是 InnoDB 表空间的一部分，不是日志轮转文件。MySQL 5.7 不支持在线删除或截断 undo 表空间，强行 rm undo_001 会导致：
- 实例无法重启，报错类似
InnoDB: Operating system error number 2 in a file operation或更严重的tablespace mismatch - 即使侥幸启动，也可能触发
Assertion failure或数据字典损坏 - 备份工具（如 xtrabackup）会校验 undo 表空间一致性，缺失文件将导致备份失败
真正能做的“恢复”动作只有两种
所谓“恢复”，在 5.7 场景下实际只有两个务实操作方向：
- 对仍在运行的未提交事务：联系应用确认是否可
KILL [thread_id]，之后 purge 会逐步回收 undo 空间 - 对已崩溃但未完成写入的事务：什么都不用做——InnoDB 启动时自动扫描 undo log 并回滚，输出日志里会出现
Rolling back transaction，服务就绪即表示完成 - 如果你真想“找回”被回滚的数据，唯一可靠路径是：从最近一次全量备份 + binlog 增量恢复，undo log 本身不保存可导出的原始行数据
最容易被忽略的一点是：很多 DBA 在看到 History list length 高时第一反应是调大 innodb_max_undo_log_size，其实这只会延缓问题爆发，治标不治本。核心永远是控制事务生命周期——应用层设置合理的 statement timeout、避免在事务里做 HTTP 调用或 sleep，比任何数据库参数调整都管用。
