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错误主动重试或回滚
