MySQL事务回滚失败，通常不是“回滚指令没执行”，而是事务状态、SQL语法、存储引擎或程序逻辑层面出了问题。关键要先确认：事务是否真的处于可回滚状态？有没有被自动提交？有没有隐式提交操作？
检查事务是否已提交或自动结束
MySQL中事务在以下情况会自动提交，导致ROLLBACK无效：
执行了DDL语句（如CREATE、
DROP、
ALTER），触发隐式提交 开启了自动提交（
autocommit=1），每条SQL单独成事务，
START TRANSACTION后未显式
COMMIT或
ROLLBACK，但后续又执行了DDL或某些管理命令 客户端异常断开，且未设置
wait_timeout或
interactive_timeout足够长，连接中断导致事务被服务端自动回滚（但此时你无法控制）
建议：执行
SELECT @@autocommit;确认模式；事务内避免混用DML和DDL；用
SHOW ENGINE INNODB STATUS\G查看最近事务状态。
确认存储引擎是否支持事务
只有InnoDB、NDB等事务型引擎支持回滚。如果表是MyISAM引擎：
START TRANSACTION和
ROLLBACK语法虽不报错，但实际无效果 执行
SHOW CREATE TABLE table_name;检查引擎类型 可临时转换：
ALTER TABLE table_name ENGINE=InnoDB;（注意锁表与数据一致性）
排查SQL执行过程中的异常中断
程序中调用
ROLLBACK失败，常见原因： 数据库连接已断开（网络超时、连接池回收），执行
ROLLBACK时抛出异常但被忽略 事务嵌套使用不当（MySQL不支持真正的SAVEPOINT嵌套事务，仅支持单层+保存点） 在存储过程中未正确处理异常，例如未用
DECLARE HANDLER捕获SQLEXCEPTION，导致错误后流程跳出，
ROLLBACK未被执行
建议：在应用代码中，把
ROLLBACK放在
finally或
catch块中确保执行；存储过程中用
DECLARE EXIT HANDLER FOR SQLEXCEPTION包裹关键逻辑。
验证回滚是否真正生效
有时误以为回滚失败，其实是查询方式不对：
在另一个未开启事务的会话中查数据——能看到已提交数据，但看不到本事务未提交的变更，也看不到已回滚的中间态 回滚后未重新查询，或查询语句本身有缓存/代理层干扰 使用了SELECT ... FOR UPDATE或
LOCK IN SHARE MODE但未提交，其他会话被阻塞，误判为“卡住”而非回滚失败
建议：回滚后，在同一连接中立即执行
SELECT验证；或在新会话中查表确认数据是否回到事务前状态。
