说到数据库，很多人第一反应就是存数据的地方，但真正干过运维或者写过业务系统的都知道，数据库最让人头疼的从来不是存多少，而是出了故障怎么把数据捞回来。事务这个概念，教科书里写得清清楚楚，ACID四个字母背得滚瓜烂熟，可真到了生产环境，一个进程崩了、一台机器断电了、或者磁盘莫名其妙报错，那些理论立马变成了一堆需要动手解决的现实问题。今天这篇东西，不打算绕弯子，直接聊聊事务故障时数据库到底怎么恢复，回滚和重做这两条路又是怎么走的。
先理清楚一个基本事实：事务故障分两种，一种是事务自己执行到一半发现逻辑错了，主动回滚；另一种是系统出了幺蛾子，比如进程被杀、内存爆掉、硬件抽风，事务还没来得及提交就被硬生生掐断。这两种情况，数据库的恢复策略其实是一样的——把未提交的修改抹掉，把已提交但还没落盘的修改补上。听起来简单，但这里面藏着一个核心矛盾：数据库既要保证数据不丢，又不能为了写盘牺牲性能，所以它搞了个折中方案——日志先行，也就是常说的WAL（Write-Ahead Logging）。所有修改先写日志，再改内存，才刷磁盘。
这个日志到底长什么样？说白了就是记录“谁在什么时候改了哪个页面的哪个位置，改成了什么值”，外加一个事务ID和提交标记。有了这个底子，恢复的时候就有章可循了。假设数据库刚启动，发现日志里有个事务写了“BEGIN”但没写“COMMIT”，那这个事务就是没提交的，它的所有修改都得撤销。怎么撤销？不是把数据翻回旧值那么简单，而是用日志里记录的前像（即修改前的值）去覆盖当前值。这就是回滚的本质——拿旧值盖新值，把事务留下的痕迹擦干净。
但回滚有个坑，就是如果事务已经修改了多个页面，而且这些页面已经部分刷到了磁盘上，那回滚就得小心了。你不能只撤销内存里的改动，磁盘上已经写进去的那些脏页也得处理。这时候就涉及到恢复的粒度问题了——是整页恢复，还是只恢复日志里记录的那一小块？多数数据库采用页级恢复，因为每次IO的最小单位就是页，你不可能只改一个字节就单独刷一次盘。所以回滚的时候，数据库会检查每个脏页有没有对应的撤销日志，有就做反向操作，没有就跳过。
再说重做，也就是REDO。这个方向正好反过来：事务已经提交了，COMMIT日志也写了，但数据页还没来得及刷到磁盘上，结果系统崩了。重启之后，你发现提交记录还在，但实际数据是旧的，这时候就得把日志里的后像（即修改后的值）重新应用到数据页上。重做比回滚简单，因为它不用考虑逻辑上的先后顺序，只要按照日志顺序把提交过的事务重新播放一遍就行。但重做也有麻烦事，比如日志文件被截断了、日志扇区坏了，或者恢复过程中又崩了一次，那就得引入检查点机制来兜底。
检查点这东西，说白了就是给恢复划一条起跑线。数据库定期把内存里的脏页刷到磁盘，同时记一个检查点位置，表示“这个时刻之前的所有提交事务，数据都已经落盘了”。恢复的时候，只需要从检查点之后的日志开始处理，不用从头扫到尾。这玩意儿看似不起眼，实则是恢复性能的关键。没有检查点，每次重启都要扫描全部日志，数据量一大，恢复时间能拖到天荒地老；有了检查点，恢复时间就被压缩到可控范围内。
但这里得插一句，回滚和重做并不是孤立的两条路，实际恢复过程往往是两者混合的。比如一个事务在崩溃前已经写了一半的日志，既有前像又有后像，恢复引擎就得先判断它提交了没有。提交了，就重做后像；没提交，就回滚前像。而且恢复顺序也有讲究——先做REDO，再做UNDO。为什么？因为REDO阶段要尽量把数据推进到最新状态，这样UNDO阶段才能基于一个相对完整的数据视图去撤销未提交事务的修改。你要是先撤销再重做，可能会把已提交事务的修改给覆盖掉，那就乱套了。
还有一个容易被忽视的细节：回滚操作本身也要写日志。你可能觉得奇怪，撤销一个未提交的事务，怎么还要写日志？因为回滚过程中如果系统又崩了，下次恢复还得知道回滚进行到哪一步了。所以回滚日志（UNDO日志）也会记录回滚的进度，保证回滚操作是幂等的——哪怕回滚到一半崩溃，重启后还能接着继续回滚，不会出现回滚了又没回滚完的尴尬局面。这个设计虽然增加了一点IO开销，但对于恢复的可靠性来说是必要的。
讲到这里，得提一下不同数据库在这套机制上的具体实现差异。PostgreSQL用了一个叫“多版本并发控制”的东西，每个事务修改数据时，旧版本不会立刻删掉，而是保留在页面里，回滚的时候只需要把版本链指回旧版本就行，不需要真的覆盖数据。MySQL的InnoDB则是用UNDO日志来记录前像，回滚时逐条反向执行。SQL Server走的是另一条路，它把回滚和重做都放在同一个日志流里，恢复时靠一个LSN（日志序列号）来定位。这些差异看着复杂，但核心逻辑都是同样的两板斧：日志先行，加上前像后像。
说点实际操作层面的东西。恢复策略定得再好，真到了故障现场，还是要看运维人员的判断。是直接重启数据库走自动恢复，还是先备份数据再手动介入？如果日志文件损坏了，自动恢复走不通，就得考虑用最近的备份加上归档日志做时间点恢复。这里面有个权衡：恢复的完整性重要，还是恢复的速度重要？有些场景下，业务等不起，宁可丢掉最近几分钟的数据也要先把服务拉起来；有些场景，比如金融系统，一分一毫都不能差，那就得等恢复彻底完成。所以，回滚和重做方法本身是标准化的，但怎么用、用到什么程度，永远取决于你对业务连续性和数据安全性的取舍。
说到底，数据库故障恢复这事，本质上就是一场跟时间和数据的拉锯战。事务回滚和重做，一个负责清理没搞完的事，一个负责补上该做没做的事，两者配合好了，数据库就能从各种意外中爬起来。但真正让人头疼的从来不是这些标准动作，而是那些日志写了一半、磁盘坏了一块、网络闪断导致的乱七八糟的中间状态。这时候，日志的完整性和检查点的频率就成了救命稻草。所以别光盯着回滚和重做这两个词，背后的日志设计才是真正的核心。下次再遇到数据库崩溃，别慌，先看日志，再判断该回滚还是该重做，心里有数了，事情就解决了一半。
