mysql 8.0回滚段性能更优，因默认undo表空间增至96个、自动截断启用且purge线程与undo生命周期解耦；写入分散缓解i/o热点，空间及时回收避免碎片，purge并行化减少阻塞。
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
innodb_undo_tablespaces 默认值更高，innodb_undo_log_truncate 默认启用，且 undo 日志写入路径与 purge 线程协同更紧密——这是 MySQL 8.0 回滚段性能优化更出色的根本原因。
undo 表空间默认配置已为高并发预设
MySQL 8.0.30+ 将innodb_undo_tablespaces 默认值设为 96，远高于 5.7 的 0（即仅使用系统表空间）或手动配置常见的 2–4。这意味着：
- undo 日志写入天然分散到多个独立文件，缓解单个文件的 I/O 热点和 segment header 锁争用
- 每个 undo tablespace 内部可并行分配 undo log segment，避免大事务间隐式串行化
- 无需 DBA 手动调参就能获得多文件带来的并发优势；而 5.7 必须显式开启独立 undo 表空间且数量有限
innodb_undo_logs 在 5.7 已废弃，8.0 完全移除，不再需要纠结这个过时参数。
undo 自动截断（truncate）默认开启且更可控
8.0 默认启用innodb_undo_log_truncate=ON，且配合 innodb_max_undo_log_size（默认 1G，建议调至 2–4G）实现“用完即清”：
- 长事务结束后，其占用的 undo space 能被后台线程及时回收，避免旧段残留挤压新事务写入空间
- 若关闭该选项（如 5.7 常见配置），undo 表空间只增不减，碎片累积后，新事务写入需频繁页分裂和查找空闲 slot，I/O 延迟陡增
- truncate 不是实时执行，而是按 space 级别批量清理，对正在运行的事务无干扰
innodb_max_undo_log_size 设得过小（如 128M），导致每小时触发多次 truncate，反而拖慢写入。
purge 线程与 undo 生命周期深度解耦
8.0 的 purge 机制不再强依赖于 rollback 操作本身：- 回滚动作（rollback）只负责从 undo log 中读取并恢复数据，不承担清理历史版本的责任
- purge 线程由
innodb_purge_threads控制（8.0 默认 4，5.7 默认 1），能并行清理已提交事务的 undo 记录 - 当出现 “KILL 后卡在 ROLLING BACK” 时，大概率不是回滚慢，而是 purge 被其他长事务阻塞（因
purge_lsn无法推进）
SHOW ENGINE INNODB STATUS，观察 PURGE DONE FOR 行是否停滞；若停滞，检查是否存在 TRX_STATE: RUNNING 但 TRX_STARTED 时间极长的事务。
真正影响回滚响应时间的，从来不是“undo 怎么回放”，而是“undo 是否早已写爆、是否还在被 purge 卡住”。8.0 把这三件事——写入分散、空间回收、清理卸载——都做了默认级优化，而不是留给用户靠经验硬调。
