MySQL大事务致Undo耗尽的本质是历史版本堆积、purge阻塞与空间无法释放的连锁反应，需立即定位长事务、加速purge清理、安全缩容undo表空间，并从应用与配置双端防止复发。
MySQL因大事务导致Undo回滚段耗尽、写服务中断，本质是历史版本堆积 + purge阻塞 + 空间无法释放的连锁反应。这不是简单“重启”或“删数据”能解决的问题，关键在快速疏通purge链路、释放undo空间、并阻止新压力注入。
立即定位元凶：查长事务与undo积压程度
先不动配置、不杀线程，用三句SQL锁定问题源头：
- 查活跃长事务：SELECT trx_id, trx_started, TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) AS sec, trx_state, trx_rows_modified, trx_mysql_thread_id FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 600;
- 看undo积压水位：执行 SHOW ENGINE INNODB STATUS\G，搜索 HISTORY LIST LENGTH —— 若持续 > 5000（尤其上万），说明purge严重滞后；
- 确认undo表空间是否独立启用：SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'innodb_undo_tablespaces'; 值必须 > 0，后续缩容才可行。
紧急止血：加速purge清理，释放undo空间
不能等回滚完成，要让已提交事务的undo日志尽快被回收：
- 临时提高purge频率：SET GLOBAL innodb_purge_rseg_truncate_frequency = 1;（默认128，值越小purge越激进，但会增加CPU负载）；
- 极端磁盘将满时，可短时启用强清策略：SET GLOBAL innodb_max_purge_lag = 0;（仅限10分钟内使用，否则MVCC读会大量触发Lock wait timeout exceeded）；
- 观察 HISTORY LIST LENGTH 是否开始下降，同时用 iostat -x 1 看 await 是否回落 —— 若仍卡在高IO，说明undo page分散读取严重，需配合调大 innodb_buffer_pool_size 缓解随机IO压力。
安全缩容：停用并删除闲置undo表空间
只有当purge跟上、对应undo表空间状态变为 INACTIVE 后，才能真正释放磁盘空间：
- 先标记待删空间为非活跃：ALTER UNDO TABLESPACE undo_001 INACTIVE;
- 等待其状态变为 INACTIVE（查 SELECT NAME, STATE FROM information_schema.FILES WHERE SPACE_TYPE = 'Undo';）；
- 确认无活跃事务依赖后执行：DROP UNDO TABLESPACE undo_001;（MySQL 8.0.23+ 支持）；
- 注意：不可直接删除物理文件，也不可在ACTIVE状态下DROP，否则实例可能崩溃。
防止复发：从应用与配置双端堵住长事务
故障恢复后若不加固，一周内大概率复现：
- 应用层强制事务超时：在ORM中设置 transaction timeout（如 Django 的 @transaction.atomic(using='default', timeout=30)），或在连接池层配置 wait_timeout 和 innodb_lock_wait_timeout；
- 禁用隐式长事务陷阱：避免在事务内做HTTP调用、文件读写、sleep、循环重试等耗时操作；
- 批量操作必须分片：单事务修改行数建议 ≤ 1万，配合 COMMIT 后短暂休眠（如 100ms），降低锁持有时间和undo生成速率；
- 监控告警落地：对 INFORMATION_SCHEMA.INNODB_TRX 中 duration_sec > 300 的事务自动告警，对 HISTORY LIST LENGTH > 3000 持续5分钟触发短信预警。
