事务回滚慢的根源在于undo log生成与持久化过程压垮i/o和buffer pool，而非回滚动作本身；大事务、全表更新、长事务及purge阻塞是主因，优化需从sql行为和事务设计入手。
事务回滚时 undo log 写入为什么慢
回滚本身不慢，慢在回滚前的 undo log 已经写满了——MySQL 在事务执行过程中就持续写入 undo log，用于支撑 MVCC 和回滚。一旦事务大（比如批量更新百万行），undo log 体积暴涨，不仅占空间，还触发频繁的磁盘刷写和页分裂，最终拖慢整个事务生命周期，包括回滚阶段。
关键点在于：回滚性能瓶颈往往不是“回滚动作”，而是“undo log 的生成与持久化过程”本身已经把 I/O 和 buffer pool 压垮了。
-
innodb_undo_log_truncate=ON必须开启，否则 undo 表空间永不收缩，旧段残留导致新事务写入更慢 - 避免长事务：一个运行 10 分钟的事务，可能已生成几百 MB undo，此时哪怕只回滚一行，也要扫描大量 undo 记录
- 高并发下多个大事务竞争
undo logsegment header 锁，造成隐式串行化
如何减少 undo log 的实际写入量
不是靠配置开关，而是从 SQL 行为上压缩 undo 数据规模。MySQL 对每行更新/删除都记一条 undo record，所以行数越少、字段越窄、修改越少，undo 越轻。
- 用
WHERE精确过滤，避免UPDATE t SET a=1全表扫——全表更新 = 全表 undo 记录 - 拆分大事务：把
UPDATE ... LIMIT 10000改成循环 + 小批量提交，每次只产生少量 undo，且能及时 truncate - 删除优先走
TRUNCATE TABLE或分区DROP PARTITION，它们不走 undo，直接释放段 - 对只读场景，显式加
START TRANSACTION READ ONLY，彻底绕过 undo 分配
innodb_undo_* 配置哪些真有用
多数线上环境默认配置就够用，盲目调参反而容易出问题。真正值得检查的只有三个：
-
innodb_undo_tablespaces：设为大于 2 的偶数（如 4），分散 undo 写入热点；但 MySQL 8.0.30+ 已默认 96，无需改 -
innodb_undo_log_encrypt=OFF：加密 undo 会显著增加 CPU 和延迟，除非合规强要求，否则关掉 -
innodb_max_undo_log_size：控制单个 undo tablespace 自动 truncate 的阈值（默认 1G），设太小会导致频繁 truncate 影响性能，设太大则空间浪费；建议 2–4G 之间按磁盘余量调整
别碰 innodb_undo_logs（5.7 已废弃）或 innodb_purge_batch_size（purge 线程行为，和回滚无直接关系）。
回滚中止不了？可能是 purge 拖累而非 undo 本身
有时执行 KILL 后事务状态卡在 ROLLING BACK 几分钟，其实不是 undo 回放慢，而是后台 purge thread 正在清理该事务留下的历史版本，而它被其他长事务阻塞（因为 purge 只能清理到最老活跃事务的 low water mark 之后）。
- 查
SHOW ENGINE INNODB STATUS里的PURGE PROCESSED和HISTORY LIST LENGTH，如果后者长期 > 10000，说明 purge 落后严重 - 监控
Innodb_purge_delay是否被动态设置——某些运维脚本会误开它来“限速 purge”，结果让历史版本堆积 - 避免在业务高峰执行大 DELETE，这类操作留下的 history 版本最多，purge 压力最大
真正难优化的从来不是回滚指令，而是让事务从一开始就不需要回滚——控制大小、时长、隔离级别，比事后调优 undo 参数有效十倍。
