MySQL回滚事务用ROLLBACK语句撤销未提交操作，依赖InnoDB的Undo日志实现反向操作；需确认事务活跃、autocommit状态及未提交，否则回滚无效。
MySQL回滚事务，核心就是用 ROLLBACK 语句撤销尚未提交的修改。它不是“恢复历史数据”，而是撤回当前事务中已执行但未提交的所有 SQL 操作，依赖 InnoDB 的 Undo 日志实现。
基本回滚语法与触发时机
最常用、最直接的方式是显式执行：
- ROLLBACK; —— 回滚整个当前事务，回到 START TRANSACTION 或 BEGIN 开启时的状态
- ROLLBACK TO SAVEPOINT sp_name; —— 只回滚到指定保存点，保留该点之前的操作
- SAVEPOINT sp_name; 必须先定义，才能部分回滚（例如：SAVEPOINT before_update;）
注意：如果没手动开启事务（即 autocommit=1），每条 SQL 默认自成一个事务，执行完立刻提交，此时 ROLLBACK 无效——因为事务早已结束。
自动回滚的几种常见情况
有些错误发生时，MySQL 会自动触发回滚，无需人工干预：
- 遇到死锁：InnoDB 主动选择一个事务回滚，释放锁资源
- 锁等待超时（默认 innodb_lock_wait_timeout=50 秒）：只回滚最后一条语句（非整个事务）
- 设置 innodb_rollback_on_timeout=ON 后，锁超时将回滚整个事务（慎用，可能破坏业务逻辑一致性）
- DDL 语句（如 ALTER TABLE）会隐式提交当前事务，之后无法再回滚前面的操作
回滚前必须确认的三件事
避免“以为回滚了，其实没生效”这类问题：
- 检查是否处于活跃事务中：执行 SELECT @@in_transaction;，返回 1 才表示有未提交事务
- 确认 autocommit 状态：SELECT @@autocommit;，为 0 表示手动提交模式，适合事务控制；为 1 时需先用 START TRANSACTION 开启事务
- 验证是否已 COMMIT：一旦执行 COMMIT，就不可逆，ROLLBACK 将报错 “No transaction in progress”
回滚的本质：Undo 日志在做什么
回滚不是从磁盘读旧数据，而是靠 Undo 记录“反向操作”：
- INSERT 回滚 → 删除刚插入的行（仅需主键）
- UPDATE 回滚 → 用 Undo 中保存的旧值覆盖当前字段
- DELETE 回滚 → 清除删除标记（记录仍存在，只是恢复可见性）
- InnoDB 按 Undo 链表逆序执行这些操作，确保逻辑顺序正确
所以回滚速度取决于事务修改的行数和 Undo 日志大小，大事务回滚可能耗时较长，且占用 undo 表空间。
