大事务导致undo log膨胀是因为MVCC要求保留旧版本数据，活跃事务未提交时purge线程无法清理对应undo，加之innodb_max_purge_lag配置不当会加剧空间耗尽。
为什么大事务会让 undo log 膨胀到占满磁盘
问题的根源在于InnoDB的MVCC机制。这个机制依赖undo log来保留数据的旧版本，只要还有活跃事务——哪怕只是一个未提交的SELECT——需要读取某一行过去的快照，对应的undo log记录就会被“保护”起来，purge线程无权清理。想象一下，一个持续运行2小时的UPDATE大事务，可能产生GB级别的undo日志。此时，如果purge线程清理速度跟不上（可能是innodb_max_purge_lag设置不当，也可能是其本身性能瓶颈），这些“垃圾”数据就会不断堆积，最终不仅占满磁盘空间，甚至可能直接卡住整个实例的DML操作。
调整 innodb_max_purge_lag 不是万能解药，得看场景
这个参数常被误解为“一键清理”开关，其实它的作用更像一个“流量控制阀”。它的单位是undo log记录数，当堆积的待清理记录数超过设定阈值时，InnoDB会主动限制新的DML操作，通过插入usleep来降低写入速度——本质上，这是用牺牲一部分写入性能来换取空间安全，防止情况彻底失控。
但必须清醒认识到，它治标不治本：
- 设得太小（比如
10000）：稍有长事务就会触发限流，业务性能会感受到明显波动。 - 设得太大（比如
0或10000000）：相当于关闭了保护机制，undo日志会毫无节制地膨胀，直到磁盘告急。 - 最关键的限制：它只影响“未来”的写入，对于已经存在的长事务和堆积如山的undo记录，它没有任何清理能力。
那么，如何设置比较稳妥呢？一个经验性的初始值是innodb_max_purge_lag = 500000（大约50万条undo记录），同时可以搭配innodb_max_purge_lag_delay = 100000（微秒级延迟上限）。设置后，务必通过SHOW ENGINE INNODB STATUS命令，观察PURGE DONE部分的进度来持续调优。
必须监控长事务，而不是等报警
被动等待磁盘空间报警是下下策。MySQL本身不提供“事务运行超时”告警，所以我们必须主动出击。核心手段就是查询information_schema.INNODB_TRX系统表：
SELECT trx_id, trx_state, trx_started,
TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) AS duration_sec,
trx_mysql_thread_id, trx_query
FROM information_schema.INNODB_TRX
WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 600;
分析结果时，要重点关注这几类“危险分子”：
- 状态为
RUNNING但查询语句为NULL：这极可能是应用程序开启了事务却未正确关闭（比如忘记提交或回滚），导致连接空闲但事务挂起。 - 查询是
UPDATE或DELETE且已运行超过300秒：这类事务需要立即联系业务方确认，判断是否可以安全中断。 - 更进一步，可以关联查询
performance_schema.threads表，获取线程级别的详细信息，精准定位到发起事务的源IP和用户。
真正治本：从应用侧切断长事务源头
说到底，所有数据库层的参数调整和监控手段都只是“消防措施”。undo log膨胀的根本原因，永远在应用程序这一侧。因此，治本之策在于规范应用行为：
- 事务内禁止耗时操作：坚决避免在数据库事务中执行HTTP调用、文件读写、人为
sleep等不可控的外部操作。 - 批量操作必须分页：对于大批量更新，务必进行分页处理，建议将单个事务处理的行数控制在
1000行以内，并及时COMMIT。 - 规范ORM框架使用：使用MyBatis、Django等ORM框架时，务必显式配置
autocommit=true，避免框架的隐式事务行为跨越多个请求，意外制造出长事务。 - 设置合理的锁等待超时：通过
SET SESSION innodb_lock_wait_timeout = 5等语句，缩短锁等待时间，防止多个小事务因相互等待而“卡”成一个实质上的大事务。
最后提一个最容易被忽略的“灯下黑”问题：监控脚本本身。如果监控脚本开启了事务查询却忘记提交，那么每运行一次脚本，就可能留下一条“僵尸”长事务。这类“运维自产”的长事务，在凌晨业务低峰期最容易悄悄累积，最终成为压垮磁盘的最后一根稻草。
