Oracle/MySQL/PostgreSQL的MVCC实现及redo/undo/binlog相关概念

最近好像突然有点回归到传统的关系型/集中式数据库原理上面来了，也可能是之前一直对这些概念印象不太深刻。今天再总结一下，好让记忆深刻一些。本文主要的目的是把Oracle、MySQL、PostgreSQL三大主流的关系型数据库中关于MVCC实现及redo log、undo log及binlog的关系描述清楚。

Oracle

Oracle中只有REDO日志和UNDO日志，没有BINLOG日志的概念。
REDO日志是Oracle在线或归档重做日志文件中记录的信息，可以用于重放事务信息。REDO日志在语句执行时生成并写入到SGA中的Redo log Buffer内存中，然后在COMMIT提交时刷新到磁盘上进行持久化保存。如果正好事务提交但数据库发现故障，此时REDO日志已经落盘但实际的数据还没来得及刷新到磁盘，可以在实例恢复的时候从REDO日志中进行重做，把数据进行恢复。
UNDO日志是Oracle在UNDO段中记录的信息，用于撤销或回滚事务。当对数据进行修改时，同时也会生成UNDO日志，UNDO日志中记录了数据被修改前的值，因此当事务回滚或某种原因执行失败时可以利用UNDO日志来将数据恢复到之前的状态。
MVCC实现：简单来说，Oracle的MVCC是利用UNDO回滚段机制。由于UNDO段中保存了某个数据修改前的映像数据。当在查询数据时，首先会在UNDO段中查找该数据块的前映像，然后把前映像和current块合并形成一个CR BLOCK，通过查询CR BLOCK来满足查询数据一致性。

MySQL

MySQL中REDO、UNDO和BINGLOG日志都存在，但是只有BINLOG是Server层的日志，REDO和UNDO日志是引擎层（InnoDB）的日志，如果换成是其他引擎就未必有REDO和UNDO日志了。
BINLOG日志作为MySQL操作记录归档的日志，记录了所有对数据库的数据、表结构、索引等变更的操作，也就是说只要对数据库有变更的操作都会记录到BINLOG中。BINLOG以事件形式记录，不仅记录操作的语句，还记录了语句执行的耗时。BINLOG有三种记录格式，分别是ROW、STATEMENT、MIXED。

• ROW：基于变更的数据行进行记录，如果一个UPDATE语句修改一百行数据，就会记录100行对应的记录日志。
• STATEMENT：基于SQL语句级别的记录日志，相对于ROW模式，只会记录这个update语句。所以此模式非常节省日志空间，避免大量的IO操作。
• MIXED：混合模式。一般语句修改使用STATEMENT格式保存，如一些函数或语句无法完成主从复制的操作则采用ROW格式保存。

BINLOG写入有以下几种策略：

• sync_binlog=0，每次提交事务binlog不会马上写入磁盘，而是先写到page cache，有丢失日志的风险。
• sync_binlog=1，每次提交都会执行fsync将binlog写入到磁盘。
• sync_binlog>1，每次提交事务先写到page cache，只有等到积累了N个事务之后才fsync写入到磁盘，此设置下会有丢失N个事务日志的风险。

REDO日志属于InnoDB层的日志，用来支持InnoDB的事务特性。REDO日志的功能与上述一致。

UNDO日志也属于InnoDB层的日志，功能与上述一致。

MVCC实现：由于 InnoDB具有记录UNDO日志的能力，因此MySQL的MVCC也是通过UNDO来实现的，不过与Oracle不同的是，MySQL的MVCC是基于记录级的，它通过UNDO来形成行的版本链。

PostgreSQL

和Oracle、MySQL不同，PostgreSQL中首先没有UNDO的概念，因此不存在UNDO日志。它也没有BINLOG，BINLOG是MySQL特有的日志功能。
PostgreSQL中只有预写日志WAL，它的功能跟REDO差不多。
WAL日志：WAL与REDO差不多，当事务提交时WAL会先落盘。当数据库崩溃恢复时，使用WAL日志来恢复数据。

MVCC实现：PostgreSQL中的多版本并发是通过在表中数据行的多个版本来实现的，比如我们在更新一条记录，PostgreSQL并不是直接修改该数据，而是通过插入一条全新的数据，同时对老的数据加以标识。因此，PostgreSQL中通常需要定期对数据进行清理动作，否则会有数据膨胀的问题。