MySQL事务回滚失败主因是事务未进入可回滚状态，常见于autocommit开启、SQL错误被忽略、隐式提交（如DDL操作）或锁等待超时；需检查autocommit值、事务生命周期、错误捕获及锁状态。
MySQL事务回滚失败，通常不是“回滚指令没执行”，而是事务根本没按预期进入可回滚状态——常见原因是自动提交（autocommit）开启、SQL语法错误未被捕获、或事务被隐式提交。排查要从事务生命周期入手，重点看是否真正开启了事务、有没有意外触发提交、以及错误是否被忽略。
检查 autocommit 是否关闭
这是最常被忽略的原因。默认情况下 MySQL 的 autocommit=1，每条 SQL 都是独立事务，ROLLBACK 对它无效。
- 执行
SELECT @@autocommit;确认值是否为 0；若为 1，需先执行SET autocommit = 0; - 注意：某些客户端（如 MySQL Workbench、某些 ORM）会在连接初始化时重置 autocommit，需在业务逻辑开始前显式设置
- 使用
START TRANSACTION或BEGIN可临时关闭 autocommit，但仅对当前事务块有效
确认事务是否已被隐式提交
以下操作会**强制提交当前事务**，导致后续 ROLLBACK 无效果：
- 执行 DDL 语句（
CREATE、DROP、ALTER、TRUNCATE等） - 执行
LOCK TABLES、UNLOCK TABLES - 切换数据库（
USE db_name）在部分版本中也会触发隐式提交 - 调用某些存储函数（含修改数据的函数）也可能中断事务
建议：在事务中避免混用 DDL 和 DML；如必须，拆分为多个独立事务处理。
捕获并检查 SQL 执行错误
回滚失败往往因为“你以为执行成功了，其实某条语句已报错但被忽略”，导致后续逻辑跳过 rollback 或事务提前终止。
- 在应用层（如 Python/Java/PHP）务必检查每条 SQL 的执行返回值或异常，不能只靠最后一条语句判断
- 开启 MySQL 的
sql_mode严格模式（如STRICT_TRANS_TABLES），让无效数据插入等操作直接报错而非静默截断 - 查询
SHOW ENGINE INNODB STATUS\G中的 LATEST DETECTED DEADLOCK 或 TRANSACTIONS 部分，可发现未提交事务卡住或被 kill 的痕迹
验证事务隔离级别与锁竞争
看似回滚失败，实则是事务卡在锁等待，超时后自动回滚但应用未感知：
- 执行
SELECT @@tx_isolation;查看当前隔离级别，高并发下REPEATABLE READ易出现间隙锁阻塞 - 查锁状态：
SELECT * FROM information_schema.INNODB_TRX;看是否有长时间 RUNNING 的事务 - 查锁等待：
SELECT * FROM information_schema.INNODB_LOCK_WAITS;确认是否存在阻塞链 - 必要时调整
innodb_lock_wait_timeout（默认 50 秒），并在应用层捕获Lock wait timeout exceeded错误主动重试或回滚
