最近复习了一下Mysql事务，看到网上很多博客都把这里讲的很乱，将有些概念和名词混淆一谈，于是顺便将redo log,redo log buffer 以及buffer pool在事务处理中的详细过程和原理总结了一下。
首先数据修改操作（updata）是从磁盘将数据先加载到内存的buffer pool当中进行更改，然后再通过随机IO写入到磁盘当中更新数据
但是，由于从内存将修改后的数据写入到磁盘是随机IO，效率极低，所以为了提高效率，redo log buffer和redo log诞生了。
下图就是后来优化加入redo log和redo buffer后的事务处理流程
为了提高效率，当数据在内存中修改完成时，会先将数据的变化日志写入到redo log buffer当中，然后再将redo log buffer当中记录的数据变化日志写入到磁盘的redo log当中。
这样的话，由于磁盘当中有原数据，redo log记录的数据的变化，那么如果意外宕机，只要redo log已经更新，那么数据就不会丢失。
这样不但提高了事务并发的效率（因为日志的写入是顺序IO，极大地提高了事务并发的效率，且减轻了磁盘IO的压力
），还大大提高了安全性（宕机时由于顺序IO写入日志效率高，极大的减少了数据丢失的可能性）
下面讲讲当意外宕机后重启mysql数据恢复的全过程：
重启后通过redo log和数据文件当中的LSN对比发现，redo log日志中记录的数据变化版本要高于数据文件记录的数据版本，因此存储引擎会将redo log加载到redo log buffer中，再将数据文件中的旧数据加载到buffer pool当中，然后内存当中的buffer pool会根据redo log buffer记录的新版本数据变化进行数据更新，最后再将最新版本的数据写入到mysql的磁盘数据文件当中，完成数据的更新，极大地保证的数据的安全性。
