redo是什么？

首先明确，redo是InnoDB引擎特有的。记录着事务里对数据的修改。

在mysql中，如果修改了数据，那么事务提交前，首先会被记录成redo日志写入磁盘，等到事务提交时，再把新数据写入磁盘（你以为真的是这样）。

这也就是经常说的WAL（Write-Ahead Logging）。

redo的好处
那么为什么需要redo呢？

1.保证数据的持久性。众所周知，数据是记录在磁盘上的，如果事务提交后mysql突然挂了（比如断电之类的），那么内存里的数据，是不是就丢失了？我们数据恢复时候，通过redo 就可以恢复回来。

解释：因为我们在事务提交前都已经把相关日志写入了磁盘，所以碰到意外当然可以恢复。如果写redo的时候断电了呢？大致上可以认为事务回滚了。不过没这么简单，到底是回滚还是提交，还牵扯到bin log。我们下文会讲到。

2.redo只是记录了对数据的修改，数据会比一页数据小得多。大大减少了IO频率。

解释：显而易见吧，一条redo再怎么也不会有16k那么大吧！

当然，写redo并不是一条条写的。因为一条redo日志并不是写入的最小单位，一般来说至少都是几条一起写。这是因为一条修改语句对B+树的修改，绝大多数情况下都不会是只产生一个修改点，比如你要插入一条数据，叶子节点容不下了，那么就可能页分裂，同时还会更新许多内节点的信息。所以这一系列对底层B+树的操作，都会以一组的形式去写入磁盘。

具体的写入过程下文会讲。现在只需要知道，一个事务会包含许多SQL，而一条SQL修改语句，会产生很多组redo就行了，而这一组（学名：Mini-Transaction）才是写入的最小单元。

好奇的你可能又会问：那这一组也没法保证写入的原子性啊，写一半断电了怎么办呢？

是的，写入永远没法保证原子性，所以只能在读取的时候保证了。在一组redo日志里，结尾会有一个标志符。解析redo日志的时候，读不到这个标志符的话，这一组就不解析了。不过这个Mini-Transaction并不是为了保证事务，我个人觉得是为了保证那颗B+树不会被搞坏了。

3.redo日志的写入是顺序IO。而修改磁盘的B+树是随机IO。

解释：redo就是往一块硬盘的某个相邻的区域写就完事了。如果要直接去修改B+树，很可能这些页并不相邻，寻址会很慢的。当然，固态硬盘的随机IO会好很多。