UndoLog溢出本质是历史版本堆积与purge清理速度不匹配，高并发下需缩短事务时长、加速purge，而非单纯扩容；因长事务阻塞purge，而默认purge能力仅约300段/秒，远低于千级TPS写入速度。
UndoLog 溢出本质是历史版本堆积 + 清理跟不上写入，高并发下最直接有效的解法就是缩短事务时长、加快 purge 进度，而不是只调大空间。
为什么高并发下 UndoLog 容易溢出
InnoDB 的 MVCC 依赖 undo log 维护行版本链，每个未提交事务都会让 purge 线程无法清理其产生的旧版本。高并发写入时，若存在长事务（哪怕只有一个），history_list_length 就会持续上涨，undo 表空间不断膨胀；同时 purge 线程处理能力有限，默认每秒最多处理约 300 个 undo log 段——远低于千级 TPS 场景的生成速度。
常见错误现象包括：
- 写入变慢，
innodb_row_lock_waits上升 - 执行
SHOW ENGINE INNODB STATUS发现PURGE DONE进度长期卡住 - 磁盘空间告警，
ibdata1或独立 undo 文件持续增长，information_schema.INNODB_METRICS中undo_log_truncations计数为 0
缩短事务时长：从代码层切断源头
事务越长，undo 版本存活时间越久，这是所有优化的前提。不要指望靠调参“兜底”。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 避免在事务内做 RPC 调用、文件读写、sleep 等非数据库操作
- 拆分大事务：比如批量更新 10 万行，改用每次 1000 行 + 显式
COMMIT - 确认业务是否真需要可重复读隔离级别；部分场景可降级到
READ COMMITTED，减少 undo 版本保留量 - 检查 ORM 是否隐式开启长事务（如 Spring 的
@Transactional作用域过大）
加速 purge 和 truncate：让清理跟上生产节奏
MySQL 5.7+ 默认启用 innodb_undo_log_truncate=ON，但仅当满足条件才会触发截断。关键参数必须协同生效：
-
innodb_max_undo_log_size建议设为134217728（128MB）或268435456（256MB），不能设太大，否则单个 undo 表空间“一枝独大”，truncate 效率低 - 必须确保
innodb_undo_tablespaces >= 2（推荐 4～8），否则 truncate 无法并行执行 - purge 频率受
innodb_purge_batch_size（默认 300）和innodb_purge_rseg_truncate_frequency（默认 128）影响；高并发下可将后者调小至 32，加快 rseg 回收节奏 - 观察
INFORMATION_SCHEMA.INNODB_METRICS中undo_log_truncations是否稳定上升，若长期为 0，说明 truncate 未触发或失败
容易被忽略的硬限制与陷阱
很多团队调完参数发现没效果，问题常出在边界约束上：
-
innodb_undo_log_truncate只对独立 undo 表空间（innodb_undo_tablespaces > 0）生效；若仍用系统表空间（ibdata1），truncate 根本不工作 - truncate 不是立即收缩文件，而是标记为“可复用”，下次写入时才覆盖；要真正释放磁盘空间，需停库后删除旧 undo 文件并重启（生产慎用）
-
innodb_rollback_segments默认 128，但实际活跃段数由innodb_undo_tablespaces × 128决定；若只配了 1 个 undo 表空间，再多 rollback segment 也无意义 - 监控必须看
history_list_length（SHOW ENGINE INNODB STATUS输出顶部），它比磁盘占用更早暴露 purge 压力——超过 10000 就该预警
真正的瓶颈往往不在配置值本身，而在事务行为是否可控、purge 是否有足够资源调度、以及 undo 文件是否真正独立——这三点漏掉任一，调参只是给溢出延缓几小时而已。
