3. 数据库回滚：事务回滚（ACID）、SQL语句回滚、基于快照的回滚
数据库回滚，说白了就是「后悔药」。你执行了一串操作，发现不对劲，得退回去。我做了这么多年系统，见过太多因为回滚没设计好导致数据不一致的惨案。今天咱们就把这块掰开揉碎了讲。
3.1 事务回滚与ACID
事务回滚是数据库最基础的保障。它的核心就是ACID里的A（原子性）——要么全做，要么全不做。
ACID中的回滚保障：
- 原子性（Atomicity）：事务内的操作不可分割，失败就全部撤销
- 一致性（Consistency）：回滚后数据必须回到事务开始前的合法状态
- 隔离性（Isolation）：回滚中的事务对其他事务不可见
- 持久性（Durability）：已提交的事务不回滚
我记得有一次线上事故，一个批量更新脚本跑了半小时，结果中间一条数据违反约束。如果没有事务包裹，前面更新的几百万条就全废了。嗯，这就是原子性的价值。
3.1.1 事务回滚的实现机制
数据库内部怎么做到回滚的？核心是Undo Log（回滚日志）。
| 组件 | 作用 | 回滚时的行为 |
|---|---|---|
| Undo Log | 记录数据修改前的旧值 | 用旧值覆盖新值 |
| Redo Log | 记录已提交的修改 | 回滚时不使用，用于崩溃恢复 |
| 事务ID | 唯一标识每个事务 | 标记哪些修改需要撤销 |
| 回滚段 | 存储Undo数据的区域 | 按事务ID查找对应的Undo记录 |
流程其实很简单：
- 事务开始，分配事务ID
- 每次修改前，先把旧值写入Undo Log
- 执行修改
- 如果遇到错误或执行ROLLBACK，从Undo Log读取旧值恢复
- 释放Undo Log空间
我曾经踩过的坑：大事务长时间不提交，Undo Log会膨胀到撑爆磁盘。有一次凌晨告警，一看回滚段用了200GB。从那以后，我强制要求所有事务必须在5秒内完成，超过就报警。
3.2 SQL语句回滚
事务回滚是整体撤销，但有时候你只想撤销某一条SQL。这就涉及到SQL语句级别的回滚了。
3.2.1 隐式回滚 vs 显式回滚
| 类型 | 触发条件 | 回滚范围 | 示例 |
|---|---|---|---|
| 隐式回滚 | SQL执行出错、约束违反、死锁 | 仅当前语句 | INSERT违反唯一约束，自动回滚该INSERT |
| 显式回滚 | 手动执行ROLLBACK | 整个事务 | 检测到业务异常，执行ROLLBACK |
| 语句级回滚 | 部分数据库支持SAVEPOINT | 回滚到指定保存点 | ROLLBACK TO SAVEPOINT sp1 |
你想想看，为什么要有语句级回滚？因为有时候你只想放弃某一步操作，而不是整个事务。比如批量导入数据，前100条成功了，第101条出错了，你不想重来一遍。
3.2.2 SAVEPOINT 实战
-- 设置保存点
BEGIN;
INSERT INTO users (id, name) VALUES (1, 'Alice');
SAVEPOINT sp1;
INSERT INTO users (id, name) VALUES (2, 'Bob');
-- 这里出错了，但不想回滚Alice那条
ROLLBACK TO SAVEPOINT sp1;
-- 继续其他操作
INSERT INTO users (id, name) VALUES (3, 'Charlie');
COMMIT;
-- 最终结果：Alice和Charlie被插入，Bob被回滚我个人习惯：在复杂存储过程中，每步操作前都设置SAVEPOINT。这样出错了可以精确回滚到上一步，而不是整个事务重来。但要注意，SAVEPOINT太多会影响性能，我一般控制在5个以内。
3.3 基于快照的回滚
事务回滚和SQL回滚都是「逻辑回滚」，基于快照的回滚是「物理回滚」。说白了，就是把整个数据库恢复到某个时间点的状态。
3.3.1 快照回滚的原理
快照回滚依赖的是MVCC（多版本并发控制）。每个数据行都有多个版本，每个版本对应一个时间戳或事务ID。
3.3.2 快照回滚的三种实现方式
| 方式 | 原理 | 回滚速度 | 空间占用 | 适用场景 |
|---|---|---|---|---|
| 完整快照 | 全量拷贝数据文件 | 慢（全量拷贝） | 高（100%数据量） | 关键时间点备份 |
| 增量快照 | 只记录变化的数据块 | 中 | 中（变化量） | 频繁备份场景 |
| 差异快照 | 记录与基准快照的差异 | 快（只回滚差异） | 低 | 日常快速回滚 |
我曾经遇到的事故：有一次做数据库快照回滚，没注意快照链的长度。回滚时数据库需要遍历整个版本链，结果回滚花了40分钟，业务直接停摆。后来我强制要求快照链不超过3层，超过就合并。
3.3.3 快照回滚的实战配置
以PostgreSQL为例，快照回滚依赖的是pg_rewind和时间点恢复（PITR）。
-- 创建基础快照
SELECT pg_create_restore_point('snapshot_before_deploy_v3');
-- 查看快照列表
SELECT * FROM pg_stat_activity WHERE query LIKE '%restore_point%';
-- 回滚到指定快照（需要停止数据库）
pg_rewind --target-pgdata=/data/pgdata \
--source-server='host=192.168.1.10 port=5432 dbname=postgres' \
--restore-target-wal
-- 或者使用PITR恢复到时间点
recovery_target_time = '2024-01-15 03:00:00'我个人建议：在生产环境，快照回滚一定要先在测试环境演练。我见过有人直接在生产库执行回滚，结果因为WAL日志被清理了，回滚到一半报错，数据直接损坏。记住：快照回滚不是万能的，它依赖WAL日志的完整性。
3.4 三种回滚方式的对比与选型
| 维度 | 事务回滚 | SQL语句回滚 | 快照回滚 |
|---|---|---|---|
| 粒度 | 事务级别 | 语句/保存点级别 | 数据库/表空间级别 |
| 速度 | 快（毫秒级） | 快（毫秒级） | 慢（分钟~小时级） |
| 依赖 | Undo Log | Undo Log + SAVEPOINT | WAL + 快照文件 |
| 风险 | 大事务撑爆Undo | 保存点过多影响性能 | WAL被清理导致失败 |
| 适用场景 | 日常业务操作 | 复杂存储过程 | 版本发布回退、灾难恢复 |
你想想看，这三种方式不是互斥的，而是互补的。日常业务用事务回滚，复杂逻辑用SAVEPOINT，版本发布用快照回滚。我一般会把这三种方式都集成到部署脚本里，形成一个完整的回滚体系。
核心原则：
- 能事务回滚的，绝不用快照回滚（快照回滚代价太大）
- 快照回滚一定要有WAL完整性保障
- SAVEPOINT是事务回滚的补充，不是替代
- 所有回滚操作都要记录日志，方便事后审计
嗯，数据库回滚这块就讲到这里。记住一句话：回滚是最后一道防线，但你不能等到出事了才去想怎么回滚。提前设计好，演练好，真出事了才能从容应对。