既然已有redo(WAL)日志，为什么还需要使用undo日志？

首先明确：你对原因的理解完全正确，两个核心场景的描述都符合数据库的实现逻辑，下面先解答你提到的「为什么不能等事务提交后再更新数据结构」的疑问：

但我不理解为什么我们不能等事务提交后再更新数据结构？这听起来比维护undo日志更简单。

这种方案在真实数据库实现中完全不可行，核心原因有三个：

• 内存开销不可接受：如果所有修改都暂存在事务私有内存里到提交时再应用，遇到修改几十万甚至上百万行数据的大事务、或者运行时长几小时的长事务时，会占用大量内存，完全超出常规服务器的内存承载能力。
• 缓冲池刷盘逻辑不允许：数据库的公共缓冲池（Buffer Pool）容量有限，当内存不足时，需要将部分脏页（已经被修改的内存数据页）刷到磁盘释放空间，这些脏页里很可能包含未提交事务的修改，如果没有undo日志记录修改前的状态，这些未提交的修改落到磁盘后，事务回滚或者数据库崩溃时根本无法恢复到修改前的正确状态。
• 提交延迟过高：如果所有修改都攒到提交时一次性写入数据结构，大事务提交时会出现极高的延迟尖峰，严重影响业务可用性。

除了你提到的两个核心原因，补充一个崩溃恢复场景的必要性：

• 数据库崩溃恢复时，redo日志只会重做所有已提交的事务修改，但是崩溃时点还存在大量未提交的事务，这些事务的部分修改可能已经通过缓冲池刷到了磁盘数据文件里，必须依靠undo日志回滚这些未提交的修改，才能保证数据的最终一致性，只有redo日志的情况下无法清理这些非法的未提交修改。

最后再确认你的两点理解：

1. 事务回滚需要undo日志撤销已应用到数据结构的未提交修改，这个判断完全正确
2. MVCC快照隔离需要undo日志存储历史版本实现无锁读，这个判断也完全正确

内容的提问来源于stack exchange，提问作者user855