事务回滚时报 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 健康度，而不是等报错再去翻日志。
