Redo，Undo，Binlog

https://www.jianshu.com/p/d829df873332

https://www.jianshu.com/p/57c510f4ec28

对于面向disk的数据库，

需要把数据先写入到page中，然后成批的flush到磁盘，所以在Page没有flush前需要有log能记录下page的state

这就是Redo，所以Redo是物理的，因为记录的是Page的具体变更，用Redo的目的是恢复出之前的page

Redo本身也是要写disk，每个操作去写也不合适，所以Redo也有个buffer，在事务commit的时候才把Redo顺序写入disk

如果事务已经写入到磁盘，或者对于大事务，可能无法等到commit的时候再flush，这个时候需要rollback

rollback的时候，是需要恢复row的状态，这就需要undo，记录下row在执行事务前的值是什么，所以undo是逻辑的

因为我们只关心的是，undo后，row的值和原来一样，是不是原来的page，这个无法保证，也不重要

至于redo和binlog的区别，我就直接copy上面的了

- 层次不同。redo/undo 是 innodb 引擎层维护的，而 binlog 是 mysql server 层维护的，跟采用何种引擎没有关系，记录的是所有引擎的更新操作的日志记录。
- 记录内容不同。redo/undo 记录的是 每个页/每个数据 的修改情况，属于物理日志+逻辑日志结合的方式（redo log 是物理日志，undo log 是逻辑日志）。binlog 记录的都是事务操作内容，binlog 有三种模式：Statement（基于 SQL 语句的复制）、Row（基于行的复制） 以及 Mixed（混合模式）。不管采用的是什么模式，当然格式是二进制的，
- 记录时机不同。redo/undo 在 事务执行过程中 会不断的写入，而 binlog 是在 事务最终提交前 写入的。binlog 什么时候刷新到磁盘跟参数 sync_binlog 相关

对于面向内存的数据库

情况变了，内存数据库没有page cache

那是不是还需要Redo和Undo

内存数据库的问题，内存数据是会丢的，如何保证fail后，可以恢复

所以他也要记录Redo到磁盘，但这里的Redo的概念其实发生了变化，和page无关，所以一般也是逻辑的

Undo，内存数据库一般都是mvcc，所以不用刻意去记录undo