根本原因是没有活跃事务可回滚：ROLLBACK仅对显式开启且未提交的InnoDB事务生效；autocommit=1、DDL隐式提交、MyISAM引擎或@@in_transaction=0时，ROLLBACK静默忽略。
根本原因通常是：根本没有活跃事务可回滚，ROLLBACK 执行成功但什么也没做——它不是“撤销历史操作”的万能开关，只对当前连接中显式开启、尚未提交的 InnoDB 事务生效。
为什么 ROLLBACK 看似执行成功却没效果？
这是最常被误解的点。MySQL 的 ROLLBACK 不报错 ≠ 数据已恢复。常见静默失效场景：
-
SELECT @@autocommit;返回1：说明每条 DML（如UPDATE、DELETE）都已自动提交，ROLLBACK找不到事务，直接忽略 -
SELECT @@in_transaction;返回0：当前连接无未提交事务，ROLLBACK无事可做 - 中间执行过 DDL（如
ALTER TABLE、DROP INDEX）：会触发隐式提交，后续语句已不在原事务中 - 表引擎是
MyISAM：不支持事务，ROLLBACK对其完全无效
如何确认事务是否真在运行？
别猜，用 SQL 实时验证：
SELECT @@autocommit, @@in_transaction, @@transaction_isolation;
必须同时满足：
-
@@autocommit = 0或已显式执行过START TRANSACTION @@in_transaction = 1- 目标表
SHOW CREATE TABLE table_name中显示ENGINE=InnoDB
缺一不可。只要有一项不成立，ROLLBACK 就不会改变任何数据。
误删/误更新后想“撤回”，ROLLBACK 已经来不及了怎么办？
如果 COMMIT 已执行，或 autocommit=1 下语句已落盘，ROLLBACK 失效是设计使然，不是 bug。此时唯一可行路径是日志恢复：
- 先查
SHOW VARIABLES LIKE 'log_bin';和SHOW VARIABLES LIKE 'binlog_format';—— 必须是ON且ROW - 用
mysqlbinlog --base64-output=DECODE-ROWS -v解析对应时间段的 binlog，定位到误操作事件 - 把
DELETE转成INSERT，把UPDATE的before_values提取出来生成反向 SQL - 注意：若 binlog 已被
expire_logs_days清理，或从未开启，这条路就断了
真正容易被忽略的不是语法或命令，而是事务的边界意识：事务从 START TRANSACTION 开始，到 COMMIT 或 ROLLBACK 结束，中间不能穿插 DDL，也不能跨连接。所有“回滚失败”的抱怨，90% 都卡在这条线上。
