InnoDB作为事务性引擎，使用write-ahead logging(WAL)机制保证ACID中的Atomicity和Durability，使用undo机制保证ACID中的Consistency和Isolation。

按照WAL和undo的机制，形成以下两个原则：

1. 数据块的更改需要先写入undo。 根据这两个原则，InnoDB更新数据的基本流程可以简单的总结为：

2. 记录需要更改undo record的redo log

3. 写入redo log
4. 写入undo record

如果MySQL实例异常crash，那么重启过程中首先会进行InnoDB recovery。 即：根据last checkpoint点，顺序读取后面的redo log，按照先前滚，再回滚的原则， 应用所有的redo log。

因为redo record中记录着数据块的地址(space_id+page_no)，所以recovery的过程首先会执行合并相同数据块的操作，以加快recovery的过程。

那么问题来了

根据space_id怎么找到对应IDB数据文件？ 因为在恢复的过程中，InnoDB只load了redo文件和系统表空间文件，如何查找InnoDB的数据文件呢？

1. InnoDB的数据字典dict_table_t结构中也保存了对应关系，但数据字典受redo保护，recovery的过程中不可用。
2. 扫描datadir的所有数据文件，读取page中保存的space_id，建立space_id和数据文件的对应关系。 MySQL目前采用第二种方式，但带来了一个问题，当设置了innodb_file_per_table后，每一个表对应一个表空间，那么需要读取所有的目录下的所有Innodb数据文件，这样就会严重的影响了recovery的时间。

MySQL 5.7中，在redo log中增加了一种新的record类型，即MLOG_FILE_NAME，记录了自last checkpoint以来更改的数据文件的file name。 这样在应用的时候，直接根据文件名就可以找到数据文件。

Oracle的设计机制：

Oracle数据库recovery的过程中，有没有这个问题呢？ 答案是没有。

我们来看下Oracle的设计机制: