1）redo
作用：保证事务的持久性
MySQL作为一个存储系统，为了保证数据的可靠性，最终得落盘。但是，又为了数据写入的速度，需要引入基于内存的"缓冲池"。其实不止MySQL，这种引入缓冲来解决速度问题的思想无处不在。既然数据是先缓存在缓冲池中，然后再以某种方式刷新到磁盘，那么就存在因宕机导致的缓冲池中的数据丢失，为了解决这种情况下的数据丢失问题，引入了redo log。在其他存储系统，比如Elasticsearch中，也有类似的机制，叫translog。 但是一般讨论数据写入时，在MySQL中，一般叫事务操作，根据事务的ACID特性，如何保证 一个事务提交后Durability的保证？而这就是 redo log 的作用。当向MySQL写用户数据时， 先写redo log，然后redo log根据"某种方式"持久化到磁盘，变成redo log file，用户数据则 在"buffer"中(比如数据页、索引页)。如果发生宕机，则读取磁盘上的 redo log file 进行数据的恢复。从这个角度来说，MySQL 事务的持久性是通过 redo log 来实现的。
2）undo
作用：实现事务回滚
Undo log是InnoDB MVCC事务特性的重要组成部分。当我们对记录做了变更操作时就会产生 undo记录，Undo记录默认被记录到系统表空间(ibdata)中，但从5.6开始，也可以使用独立的Undo 表空间。 Undo记录中存储的是老版本数据，当一个旧的事务需要读取数据时，为了能读取到老版本的 数据，需要顺着undo链找到满足其可见性的记录。当版本链很长时，通常可以认为这是个比 较耗时的操作。 大多数对数据的变更操作包括INSERT/DELETE/UPDATE，其中INSERT操作在事务提交前 只对当前事务可见，因此产生的Undo日志可以在事务提交后直接删除（谁会对刚插入的数据 有可见性需求呢！！），而对于UPDATE/DELETE则需要维护多版本信息，在InnoDB里， UPDATE和DELETE操作产生的Undo日志被归成一类，即update_undo。
