如果没有 redolog 与 undolog，能否实现事务原子性和持久性？

（本文假设读者已经理解数据库事务执行的过程，本文更关注 redolog 与 undolog 存在的必要性）

1. 假设没有 redolog 与 undolog

实际上实现数据库事务的原子性和持久性，除了 Innodb 引擎中用到的 Commit log 的方式，还有 shadow paging 的方式。（具体可以查看下面这个链接，里面的配图有一点问题，但不影响理解整体的过程。

https://www.geeksforgeeks.org/shadow-paging-dbms/）

大概的过程就是拷贝多一份相关数据到 shadow table，修改后写入磁盘。最后修改数据块的指针，使原来的数据块指针指向修改后的数据块，然后事务便视为提交成功。

2. 为什么需要 redolog

redolog 是事务写入数据库前的日志记录操作，用于数据库意外断电后的数据恢复。

如果第一步可以满足事务的原子与持久化那么为什么还需要 redolog？原因很简单，性能。

为什么引入 redolog 能提高性能？

1、因为 redolog 记录的是数据变更的日志，每一条日制都是顺序追加的，比起查找、修改具体的值即随机读写提高了 IO 效率。还有其他进一步的优化，比如通过更改 redolog 写入磁盘的策略，让 redolog 先写入到内存或者是操作系统内存，从而提高 redolog 的 io 效率。

2、如果使用 shadow paging 的方式，数据的并发操作是比较困难的，因为存在 shadow table 里面的数据粒度是比较大，可以看作是好几页相关的数据，所以事务基本得用串行方式执行。而 redolog 中的日志粒度更小，所以有更强的事务并发能力。实际上是为数据隔离性的多种级别提供了可能性。

3. 为什么需要 undolog

undolog 的作用是为了宕机恢复数据或者执行回滚命令时，回滚未提交完成的事务。但是这里会有个疑问，为什么会有未提交完成的事务呢？如果事务都是先完成 redolog 的刷盘（即写入磁盘）再执行数据库上的真实修改，那么所有事务都会是提交完整的事物，不存在回滚的问题，那么也就不需要 undolog 了。原因很简单，性能。

为了提高事务写入的效率，数据库允许未完成 redolog 的事务先写入数据库，这能充分利用磁盘的 IO 性能，提高磁盘空闲时的利用率。这就是引入 undolog 的原因，是为了进一步提高性能。

但这也引入了新的问题，如果避免未提交完成但已经修改的数据被其他事务读取到呢？下次再讲讲为什么要引入事务隔离级别和 MVVC。

总结

跟架构设计是一样的，当你引入新的系统角色，引入了新的交互规则，就会增加系统的复杂度。解决了某些问题，就会产生新的问题。所以对一个系统来说，合适的设计、避免过度设计是非常重要的。

计划写一系列为什么的文章，通过思考其存在的必要性，去理解其作用，加深对知识的记忆与理解。