MySQL回滚依赖InnoDB引擎，MyISAM等不支持事务；InnoDB通过undo log前镜像还原数据，非反向执行SQL；TRUNCATE/DROP不可回滚；ROLLBACK仅对未提交DML生效，DDL会隐式提交；回滚失败多因事务已提交或连接中断。
MySQL 回滚依赖 InnoDB，MyISAM 根本不支持事务
MySQL 本身不直接实现事务回滚，回滚能力完全由底层存储引擎提供。InnoDB 是唯一在 MySQL 官方发行版中默认支持完整 ACID 事务（含回滚）的引擎；MyISAM、Memory、CSV 等引擎压根没有事务日志（undo log），执行 ROLLBACK 不会撤回任何已执行的 INSERT/UPDATE/DELETE 操作——语句会静默忽略，甚至可能报错 SAVEPOINT does not exist 或直接提示 Table 'xxx' doesn't support transactions。
检查当前表引擎：用 SHOW CREATE TABLE table_name 查看 ENGINE=InnoDB；批量确认可用 SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'your_db';
InnoDB 回滚靠 undo log，不是“把 SQL 反向执行”
InnoDB 的回滚不是重放反向 SQL（比如把 UPDATE t SET a=2 变成 UPDATE t SET a=1），而是通过 undo log 中保存的“前镜像（before image）”直接还原数据页原始状态。这意味着：
- 回滚速度与修改行数正相关，但和 SQL 复杂度无关；一条
UPDATE改 10 万行，回滚耗时主要取决于 undo log 长度和磁盘 I/O，而非 WHERE 条件是否带索引 -
TRUNCATE TABLE不写 undo log，无法回滚；DROP TABLE同理，即使在事务中执行也会立即提交 - 长事务会持续占用 undo log 空间，可能触发
ERROR 1205 (HY000): Deadlock found when trying to get lock或Lock wait timeout exceeded
显式事务中 ROLLBACK 的实际生效边界
ROLLBACK 只撤销当前事务内尚未提交的 DML 操作（INSERT/UPDATE/DELETE），对以下操作无效：
- DDL 语句（
CREATE/ALTER/DROP）在大多数 MySQL 版本中会隐式提交当前事务，执行后ROLLBACK对其无影响 -
SELECT不参与事务控制，无所谓回滚；但SELECT ... FOR UPDATE或LOCK IN SHARE MODE获取的锁会在ROLLBACK时释放 - 自动提交关闭（
SET autocommit = 0）后，每个语句都属于当前事务；但一旦中间执行了隐式提交语句（如CREATE TABLE），后续语句就进入新事务，之前的ROLLBACK不覆盖它们
示例：
START TRANSACTION; INSERT INTO t VALUES (1); CREATE TABLE tmp (id INT); -- 此处隐式提交，t 表插入已落地 ROLLBACK; -- 只能回滚 CREATE 之后的操作（如果还有），对 INSERT 无效
回滚失败的常见信号与排查方向
当 ROLLBACK 看似“没起作用”，大概率不是语法错误，而是事务早已被意外提交或中断：
- 客户端连接异常断开（如网络闪断、超时 kill），MySQL 会自动回滚未完成事务——但你再也看不到这个动作，只能查
information_schema.INNODB_TRX确认 trx_state 是否为ROLLING BACK - 执行
COMMIT后再发ROLLBACK，MySQL 返回Warning: Got error 1643 from storage engine（实际是 “No transaction is active”） - InnoDB 缓冲池压力大时，undo log 写入延迟可能导致
ROLLBACK命令返回快，但后台仍在异步清理——此时查表可能仍看到旧数据，需等待SHOW ENGINE INNODB STATUS中TRANSACTIONS部分显示rollback completed
真正难诊断的是跨连接事务污染：一个连接里 START TRANSACTION 后未提交，另一个连接用相同账号改了同一行并提交，前者再 ROLLBACK 就会发现数据不是自己当初读到的样子——这不是回滚失效，是 MVCC 快照已过期。
