如何在MySQL 8.0中优化事务撤销日志减少行锁阻塞-mysql教程-PHP中文网

Undo log长时间不清理的根本原因是长事务卡住最老read view，导致purge线程无法清理其后产生的历史版本；典型表现为HISTORY LIST LENGTH持续升高、SELECT FOR UPDATE变慢甚至Lock wait timeout，需优先排查trx_state='RUNNING'且trx_query IS NULL的事务。

如何在mysql 8.0中优化事务撤销日志减少行锁阻塞

为什么undo log会长时间不清理，导致行锁阻塞

undo log 本身不直接造成行锁阻塞，但它会间接延长事务的“可见旧版本”生命周期，从而让 purge 线程无法回收历史版本，最终拖慢 MVCC 快照构建和加锁判断。典型表现是：history_list_length 持续升高、SELECT FOR UPDATE 等当前读变慢、甚至出现 Lock wait timeout exceeded 错误——这不是锁没释放，而是别的事务在等你这个长事务释放 undo 版本。

根本原因往往不是 undo log 太多，而是某个事务卡住了：比如开了事务后调用外部 HTTP 接口、做文件 IO、或忘了 COMMIT；也可能应用层重试逻辑把事务撑得过长。

如何快速定位正在“钉住”undo log 的长事务

别只看 SHOW PROCESSLIST，它只显示当前运行语句，不反映事务开启时间。真正有效的是查 information_schema.innodb_trx 表：

SELECT trx_id, trx_started, trx_state, trx_mysql_thread_id,
       TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) AS duration_sec,
       trx_query
FROM information_schema.innodb_trx
WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60;

重点关注 duration_sec 超过 60 秒的记录，尤其是 trx_state = 'RUNNING' 却没执行语句（trx_query IS NULL）的情况——这基本就是“开着事务挂起”的典型。

trx_started 时间戳比你预期的事务执行时间早很多，说明事务早已开始但未结束
如果 trx_query 是空，且 trx_state 是 RUNNING，大概率是代码里 BEGIN 后没 COMMIT/ROLLBACK
配合 performance_schema.threads 查线程关联的应用名或 host，能更快定位到具体服务模块

关键参数配置：启用截断 + 控制回滚段争用

MySQL 8.0 默认不自动收缩 undo log 文件，必须显式启用机制。以下三项配置缺一不可：

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载

设为 ON：innodb_undo_log_truncate —— 允许 purge 线程在满足条件时尝试截断 undo 表空间
设合理阈值：innodb_max_undo_log_size（默认 1G），建议根据写入压力设为 512M～2G；太小会导致频繁截断开销，太大则浪费空间
增加并发能力：innodb_rollback_segments 默认 128，高并发写场景可调至 256 或更高，减少回滚段内部锁竞争

注意：innodb_undo_log_truncate 生效的前提是：至少有两个 undo 表空间（即 innodb_undo_tablespaces ≥ 2），否则 MySQL 不会触发截断逻辑。

应用层必须做的三件事

所有数据库参数优化都抵不过应用层一个错误的事务习惯。以下三点不是建议，是底线：

禁止在事务内做任何非数据库操作：HTTP 请求、日志写入、文件读写、sleep() 都必须移出事务块
显式事务必须配对使用：BEGIN 后必须有确定路径的 COMMIT 或 ROLLBACK，不能依赖连接关闭自动回滚（尤其连接池场景下不可靠）
读多写少场景优先用 READ COMMITTED 隔离级别：它不依赖 gap lock，也不需要维护那么长的 undo 历史链，对 history_list_length 压力明显更小

最常被忽略的是：即使用了 ORM，@Transactional 注解也可能因异常未被捕获而跳过提交，或者嵌套事务传播行为（如 REQUIRES_NEW）意外延长了外层事务生命周期。这类问题只能靠日志埋点+监控 innodb_trx 表来发现。