ROLLBACK无效的根本原因是当前无活跃事务可回滚；常见场景包括AUTOCOMMIT=1导致每条DML自动提交、DDL语句触发隐式提交、MyISAM引擎不支持事务、存储过程未配错误处理器，以及应用层未正确调用rollback()。
MySQL事务回滚不是“发生了异常才回滚”，而是“只要没显式提交，就默认可回滚”——回滚是事务的天然状态，不执行 COMMIT 就不会落库；真正需要解释的，是为什么你明明写了 ROLLBACK 却没生效。
为什么ROLLBACK命令执行了但数据没变回去
根本原因：当前没有活跃事务可回滚。常见场景包括：
-
AUTOCOMMIT = 1（默认）时，每条INSERT/UPDATE执行完立刻提交，后续ROLLBACK对它无效 - 执行过
CREATE TABLE、ALTER TABLE、TRUNCATE TABLE等 DDL 语句，触发隐式提交，事务提前结束 - 表引擎是
MyISAM，不支持事务——START TRANSACTION和ROLLBACK都被静默忽略，无报错 - 在存储过程中未声明
DECLARE EXIT HANDLER，异常后连接断开或复用，事务残留但无法回滚
为什么应用层调用conn.rollback()仍失败
数据库驱动从不自动回滚，必须由业务代码兜底。但很多失败源于“以为调了就完了”：
- Python 中用
pymysql时，cursor.execute()抛异常后，必须手动调conn.rollback()，且要确保conn还活着 - Java JDBC 中，
connection.setAutoCommit(false)后忘了在catch块里调connection.rollback()，事务就一直挂着，可能锁表 -
ROLLBACK自身也可能失败（比如网络已断），所以建议对rollback()调用也加一层try，至少记日志
为什么查 SHOW CREATE TABLE 发现是 InnoDB 还回滚不了
引擎正确只是前提，还要确认事务是否真在运行中：
- 用
SELECT @@autocommit;查当前会话是否为0；若为1，START TRANSACTION后的语句仍可能被 DDL 隐式提交 - 用
SELECT TRX_ID, TRX_STATE FROM INFORMATION_SCHEMA.INNODB_TRX;查是否有未结束事务；空结果说明事务早已结束 - 执行
ROLLBACK后再查，如果报错ERROR 1370 (42000)，大概率是“无事务可回滚”，不是权限问题
最常被忽略的一点：回滚依赖 undo log，而它只在事务执行过程中实时生成。事务一提交或隐式提交，对应 undo 日志就被清理——这时候再想回滚，连日志都没了。
