redo log里记录的只是对数据库页面的更改，它记录着类似『更改页面x 的指定偏移量的数据为k』这样的信息，是完全二进制的log(数据库原理概念上的，不是指MySQL binlog，MySQL binlog不是二进制log)；在redo log里并没有存储在某个事务的某个操这样的信息。事务的CRUD操作中的写操作会被数据库翻译成一个个的对指定页面的写，对页面的写会进一步生成一或多个redo log。数据库在页面持久化前，会确保先把redo log写入磁盘持久化。而数据库页面上记录的原值会被覆盖，数据库会使用undo log记录这个更新前的值。

每一个事务写操作(包括插入，更新，删除)，数据库要做的就是：

1.计算更新后的记录与更新前的记录的差值，把这个信息写到rollback segment里，形成undo log。由于『写rollback segment』这个动作本身也是对页面的修改，要记录这个操作的redo log。

2.在写完undo log后，数据库才把真正的对记录的更新写到直正的数据页面，这个操作也会生成对应的redo log。

在事务提交时，事务会：

1.更新它在redo log中的记录的事务状态，同样地，也会有对应的redo log生成。

2.持久化redo log缓冲区中的数据，数据库会确保当前事务所生成的所redo log都在提交状态返回给用户前被持久化，这些redo log包括undo的redo log，也包括对原如数据更新产生的log。

在数据库宕机重启后，数据库会通过下面的操作恢复，

1.启动开始时检测是否发生崩溃，然后定位到最近的一个checkpoint(一个一致的时间点)，定位在这个checkpoint时flush到磁盘的数据页，检查checksum。如果不正确，说明这个页在上次写入是不完整的，从doublewrite buffer里把正确的页读出来，并更新到buffer中的页上。

2.顺序地分析redo log，这里包括原始数据的redo log和undo log的redo log。把redo apply页面上，这样数据库就会恢复到一个同宕机前一时刻同样的(页面)状态。

3.数据库还要通过undo log标识出未提交事务，rollback未提交的事务。要把那些被未完成的事务更新的值，替换回原来的值。

innodb的事务原子性是通过两个层次上保证的，首先，redo log会保证数据库的物理上(数据库页面)同崩溃前一刻的数据库是相同的状态；其次，undo log会保证事务的原子性，即『要么都做，要么都不做』的语义。