事务回滚报 lock wait timeout exceeded 是因回滚前需获取排他锁而等待超时；应查长事务、定位阻塞源、终止无用事务，并避免事务内耗时操作。
事务回滚时报 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;找出运行超 1 分钟的事务 - 定位阻塞源头：
SELECT * FROM information_schema.INNODB_LOCK_WAITS;结合INNODB_TRX和INNODB_LOCKS关联分析 - 紧急处理：对真正无用的长事务，可用
KILL <code>trx_mysql_thread_id; 终止（注意不是 kill connection id） - 预防：业务代码中避免在事务里做 http 调用、文件读写、sleep 等耗时操作
ROLLBACK 报 Unknown Error 或直接断连
这类错误往往指向 InnoDB 存储引擎状态异常，常见于事务日志（redo log）或回滚段（undo log）损坏、磁盘满、或 mysqld 进程被强制 kill 后残留脏页未刷盘。
实操建议：
- 立刻检查磁盘空间：
df -h看datadir和innodb_log_group_home_dir（默认同 datadir）是否已满 - 检查 MySQL 错误日志（通常是
/var/log/mysql/error.log或mysqld.err），搜redo、undo、crash关键词 - 若确认是崩溃后恢复失败，不要强行启动；先备份当前
ibdata1、ib_logfile*和所有.ibd文件，再考虑用innodb_force_recovery=1~6尝试导出数据 - 日常应开启
innodb_file_per_table=ON，降低单个表损坏影响范围
事务日志（redo/undo）怎么对应到一次回滚
回滚动作本身不写 redo log，但回滚产生的“反向操作”会记入 undo log，并通过 undo log 中的 roll_ptr 指针链式组织。当执行 ROLLBACK，InnoDB 不是重放 undo，而是顺着 undo 链，把每个修改按逆序恢复成前镜像（before image）。
关键点：
- 每条 INSERT 的 undo 类型是
TRX_UNDO_INSERT_REC，回滚时直接物理删除该行 - UPDATE/delete 的 undo 是
TRX_UNDO_UPD_EXIST_REC，回滚时用旧值覆盖当前值 - undo log 存在独立的
undo tablespaces（5.7+ 默认两个），路径由innodb_undo_directory控制，不是放在 datadir 下 - 大事务会产生大量 undo，若
innodb_max_undo_log_size触发清理阈值，可能被 truncate，导致无法回滚 —— 这也是为什么超大事务要拆分
显式 ROLLBACK 失败后，连接里的事务还存在吗
只要没收到成功响应，事务状态就是不确定的。MySQL 协议层面，ROLLBACK 是一条语句，它失败意味着语句未完成，但事务上下文并未自动清除。此时连接仍处于 active transaction 状态，后续任何 DML 都会继续在这个事务里，直到显式再执行一次 ROLLBACK 或 COMMIT（后者可能报错或静默失败）。
必须手动确认：
- 执行
SELECT @@in_transaction;—— 返回 1 表示仍有活跃事务 - 查
SELECT TRX_ID, TRX_STATE, TRX_STARTED FROM information_schema.INNODB_TRX WHERE TRX_MYSQL_THREAD_ID = CONNECTION_ID(); - 不要依赖客户端自动关闭连接来“结束事务”，有些连接池会复用连接，残留事务会污染后续请求
事务回滚报错背后，真正难处理的往往是 undo 日志不可用或锁链过深——这两者都要求你提前监控事务时长和磁盘 I/O 健康度，而不是等报错再去翻日志。