以前听说，MySQL可以恢复到半个月内任意一秒的状态，惊叹的同时，心中也不免有些好奇，这是怎么做到的？
先从下面这条更新语句说起，下面是一个表的创建语句，这个表有一个主键和一个整型字段：
mysql> create table T(ID int primary key, c int);
如果要将ID=2这一行字段c的值加一，SQL语句就会这样写：
mysql> update T set c=c+1 where ID=2;
在执行语句前要先连接数据库，这是连接器的工作。
在一个表上有更新的时候，跟这个表有关的查询缓存会失效，所以这条语句就会把表T上所有缓存结果都清空。这也是一般不建议使用查询缓存的原因。
接下来，分析器会通过词法和语法解析知道这是一条更新语句。优化器决定要使用ID这个索引。然后，执行器负责具体执行，找到这一行，然后更新。
与查询流程不一样的是，更新流程还涉及两个重要的日志模块：redo log（重做日志）和binlog（归档日志）。
重要的日志模块：redo log
在酒店里，掌柜的有个粉板，专门用来记录客人的赊账信息。如果赊账的人不多，那么他可以把顾客名和账目写在板上。但如果赊账的人多了，粉板总会有记不下的时候，这个时候掌柜的一定还有一个专门记录赊账的账本。
如果有人要赊账或还账的话，掌柜一般有两种做法：
- 一种做法是直接把账本翻出来，把这次赊的账加上去或者扣除掉；
- 另一种做法是先在粉板上记下这次的账，等打样以后再把账本翻出来核算。
在生意红火柜台很忙时，掌柜一定会选择后者，因为前者的操作实在是太麻烦了。首先，你得找到这个人的赊账总额那条记录。密密麻麻几十页，掌柜要找到那个名字，可能还得带上老花镜慢慢找，找到之后再拿出算盘计算，最后再将结果写回到账本上。
这整个过程想想都觉得麻烦。相比之下，还是先在粉板上记一下方便。如果掌柜没有粉板的帮助，每次记账都得翻账本，效率是否低的让人难受。
同样，在MySQL里也有这个问题，如果每一次的更新操作都需要写进磁盘，然后磁盘也要找到对应的那条记录，然后再更新，整个过程IO成本、查找成本都很高。为了解决这个问题，MySQL的设计者就用了类似酒店掌柜粉板的思路来提升更新效率。
而粉板和账本配合的整个过程，其实就是MySQL里常说的WAL技术，全程是Write-Ahead Logging，它的关键点就是献血日志，再写磁盘，也就是先写粉板，等不忙的时候再写账本。
具体来说，当有一条记录需要更新时，InnoDB引擎就会先把记录写到redo log里面，并更新内存，这个时候更新就算完成了。同时，InnoDB会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做，这就像打样以后掌柜做的事。
如果今天赊的账不多，掌柜可以等打样以后再整理。但如果某天赊账特别多，粉板写满了，又怎么办呢？这个时候掌柜只好放下手中的活，把粉板中的一部分记录更新到账本中，然后把这些记录从粉板上擦掉，为记新账腾出空间。
与此类似，InnoDB引擎的redo log大小是固定的，比如可以配置为一组4个文件，每个文件的大小是1GB，那么这块“粉板”就可以记录4GB的操作。从头开始写，写到末尾就又回到开头循环写，如下图所示：
write pos是当前记录的位置，一边写一边后移，写到3号文件末尾就回到0号文件开头。checkpoint是当前要操作的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。
write pos和checkpoint之间是“粉板”上还空着的部分，可以用来记录新的操作，如果write pos追上checkpoint，表示“粉板”满了，这时候不能再执行新的更新，得停下来先擦掉一些记录，把checkpoint推进一下。
有了redo log，InnoDB就可以保证即使数据库发生异常重启，之前提交的数据都不会丢失，这个能力称为crash-safe。
要理解crash-safe这个概念，可以想象赊账记录的例子，只要赊账记录记在了粉板上或者写在了账本上，之后即使掌柜忘记了，比如突然停业几天，恢复生意后依然可以通过账本和粉板上的数据明确赊账账目。