redo log
描述
redolog：重做日志，记录的是事务提交时数据页的物理修改，事务的持久性就需要依赖重做日志，它包含两个部分:该日志由两部分组成:redo log buffer(内存)、redo log file(磁盘)当事务提交之后，所有的修改信息，都会存储在重做日志里面，在刷新脏页到磁盘，发生错误的时候，恢复数据用的。
redo log 操作流程
客户端进行事务操作的时候，先向Mysql发起操作请求，对于Innodb来说，分为内存结构和磁盘结构，磁盘结构存放了很多的数据文件xx.idb，内存结构内有块区域叫做缓冲池，缓冲池中缓存了一个个数据页，当客户端发起事务操作，比如执行一条update语句，它默认操作的是缓冲池，如果缓冲池没有对应的数据，就会有后台线程把数据从磁盘读取出来，然后缓存在缓冲池中，接下来的更新操作就是更新缓冲池里面的数据页，这时缓冲池的数据也进行了更新，但是磁盘的数据还没有进行修改，这个数据也我们叫做脏页，脏页会在一定时机右后台管理线程刷到磁盘上，这时候缓冲池和磁盘的数据就保持一致了，但是脏页的数据不是实时刷新的，而是在一定时间后，通过后台线程去把脏页刷到磁盘，如果往磁盘上刷的时候出错了，这时候事务已经提交了，最后脏页往磁盘上刷的时候失败，这时候持久性就没有了保障，实际上当我们对缓冲池里面的数据修改后，他会将修改的内容记录在redo log bugger里面，然后当事务提交的时候，这个变化日志ib_logfile就会直接被刷到磁盘上，然后过一段时间进行脏页刷新的时候，如果出错了，就可以通过redo log来恢复，因为redo log 记录了当此数据的变化。如果没有redo log直接把数据刷到磁盘，这就造成了很严重的性能问题，因为我们在事务里面操作的记录的时候，这些记录基本上都是随机分布在数据页的，这也就意味着会产生大量的磁盘IO，性能影响是很大的，但是有了redo log之后，事务的时候我们只是把日志刷到磁盘，由于它是日志文件，日志文件都是追加写，所以是顺序磁盘IO。顺序磁盘IO的性能要比随机磁盘IO的性能高很多，等过一段时间之后，再把脏页的数据刷新到磁盘，脏页的数据刷新到磁盘后，其实对应的redo log日志就没有存在意义了，所以每隔一段时间redo log日志就会被清理一次。 redo log只是记录了数据变更的部分，当脏页刷新到磁盘的时候，是以页为单位进行更新的，如果这个过程发生了系统断电或者崩溃，可能会导致磁盘上这个数据也损坏，所以脏页在刷新之前，要先写道双写缓冲区，这样即使刷新脏页的时候断电，也可以通过双写缓冲区进行恢复。即便写到双写缓冲区的时候断电了，原来的数据页也不会被损坏，即使被损坏了，我们还有redo log可以恢复修改的内容。这样便提高了数据的安全性。
undo log
描述
1.用于记录数据被修改前的内容，提供回滚操作，以此来保证事务的原子性。 2.用于MVCC（多版本并发控制） 3.记录逻辑日志，当我们在执行insert语句的时候，他则会记录一个对应的delete语句，我们执行update语句的时候，他则会记录一个相反的update语句。总而言之（记录数据被修改前的状态），我们执行roll back的时候，就可以从undo log的里面读取对应的数据内容进行回滚，这样就保证了事务的原子性，undo log会在事务执行的时候产生，事务提交的时候undo log不会立马删除，还会检查MCVCC是否用到了undo log，确认没用之后才会删除。
