大事务回滚慢的根本原因是undo log过大和purge线程被阻塞，而非撤销逻辑本身慢；表现为history list length持续上万、磁盘随机io高、回滚过程反复读取分散undo page，且长事务会阻塞purge导致undo space耗尽。
大事务回滚慢，根本不是“撤销太慢”，而是 undo log 太大 + purge 卡住
回滚变卡，90% 的情况不是因为 MySQL “算不过来”，而是 undo log 文件太大、磁盘随机读高，或者 purge 线程被压住没法及时清理旧版本。你看到 ROLLBACK 命令卡住几十秒甚至几分钟，背后往往是 History list length 上万（查 SHOW ENGINE INNODB STATUS），undo page 分散在磁盘各处，回滚过程得反复跳着读。
更隐蔽的问题是：purge 线程本身被长事务阻塞——只要有一个事务没提交，它产生的所有 undo log 都不能被 purge，整个链就堵死。这时哪怕其他事务只改一行，也会因 undo space 不够而触发 ERROR 1114 (HY000): The table 'xxx' is full。
- 立即检查：
SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'innodb_undo_tablespaces';，值 > 0 才说明用了独立 undo 表空间，后续缩容才可行 - 看历史列表长度：
SHOW ENGINE INNODB STATUS\G里找HISTORY LIST LENGTH，持续 > 5000 就得干预 - 别信“我 autocommit=1 就安全”——Django 的
@transaction.atomic、SQLAlchemy 的session.begin()都会隐式开事务，漏commit或rollback就等于挂起一个长事务
Undo 表空间爆满时，不能删数据也不能停库，只能在线加速 purge
磁盘快满了，INSERT 直接报错，但此时删业务表数据没用（undo 不随数据删而释放），停库重建更是下策（可能丢未刷盘的 redo）。真正能动的手脚，是让 purge 线程跑得更快、更勤。
- 临时提频：
SET GLOBAL innodb_purge_rseg_truncate_frequency = 1;（默认 128，越小 purge 越激进） - 紧急清压（慎用）：
SET GLOBAL innodb_max_purge_lag = 0;，这会让已提交事务的 undo 立刻可删，但会加重 MVCC 读取压力，仅限磁盘将满的 10 分钟窗口 - 确认 purge 跟上了再缩容：
ALTER UNDO TABLESPACE <code>undo_001INACTIVE; → 等状态变成INACTIVE→DROP UNDO TABLESPACE <code>undo_001;（MySQL 8.0.23+ 支持）
回滚报 Lock wait timeout exceeded？你在等锁，不是在回滚
这个错误名极具误导性。它不是回滚失败，而是 MySQL 在执行 ROLLBACK 前，先尝试获取自己修改过的那些行的排他锁——结果发现这些行正被另一个长事务锁着，等了 innodb_lock_wait_timeout（默认 50 秒）还没等到，就直接报错退出。
- 查真凶：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW()) - TIME_TO_SEC(TRX_STARTED) > 60; - KILL 要精准：
KILL <code>trx_mysql_thread_id;（不是KILL CONNECTION id），否则只是断连，事务还在跑 - 预防比抢救重要：事务里做 HTTP 请求、调外部 API、读大文件、
sleep(5)……任何超 1 秒的非 SQL 操作，都该挪到事务外
innodb_rollback_on_timeout 开还是关？开，但应用层必须兜底重试
默认 OFF 是危险的：语句超时后事务还活着，锁不放、undo 不清，后续所有操作都被拖累。设为 ON 后，超时直接整事务回滚，资源立刻释放——但代价是业务逻辑可能被截断。
- 必须同步改代码：捕获
ERROR 1205 (40001)（死锁）和ERROR 1205 (40001): Lock wait timeout exceeded，做幂等重试或补偿 - 注意例外：该配置对
START TRANSACTION WITH CONSISTENT SNAPSHOT和 XA 事务无效 - 上线前验证：用
SELECT SLEEP(60);模拟长阻塞，确认超时后连接是否真释放、锁是否真清除
最常被忽略的一点：回滚性能问题从来不是孤立的 undo 配置问题，它总是和事务设计、锁粒度、应用调用链深度绑在一起。单调大 innodb_undo_tablespaces 或加 purge 线程，治标不治本；真正要盯的是每个事务里有没有不该出现的 curl_exec、fopen、time.sleep，以及每条 UPDATE 是否真的需要锁全表。
