前面讲过一条查询语句的执行过程一般经过连接器，分析器，优化器，执行器等功能模块，最后到达存储引擎。接下来聊的是一条更新语句的执行流程又是怎样的呢？
你相信MySQL可以恢复半个月内任意一秒的状态吗？ 答案是可以的。
update T set c=c+1 where ID=2
前面我们说过，在一个表上有更新的时候，跟这个表有关的查询缓存会失效，所以这条语句就会把表 T 上所有缓存结果都清空。这也就是我们一般不建议使用查询缓存的原因。
分析器会通过词法和语法解析知道这是一条更新语句。优化器决定要使用 ID 这个索引。然后，执行器负责具体执行，找到这一行，然后更新。
与查询流程不一样的是,更新的流程还会涉及到两个很重要的日志模块
redo log(重要日志)：redo log 是 InnoDB 引擎特有的
当一条语句需要更新的时候，MySQL会先把需要修改的信息写在日志上，等到空闲的时候才会去更新磁盘的信息，但是填写日志的大小是固定的。
如图所示：redo log 大小分为4个文件
索引从0到3,每次写日志从0号文件开始写，一直写到3号文件，一直这样循环下去。
write pos 是当前记录的位置，一边写一边后移，写到第 3 号文件末尾后就回到 0 号文件开头。checkpoint 是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。
write pos 和 checkpoint 之间的是“粉板”上还空着的部分，可以用来记录新的操作。如果 write pos 追上 checkpoint，这时候执行新的更新，得停下来先擦掉一些记录，把 checkpoint 推进一下。有了 redo log，InnoDB 就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为crash-safe。
bin log（归档日志）：MySQL 的 Server 层实现的，所有引擎都可以使用。
MySQL从整体来看分为两层：一个是Server层，一个是引擎层。
redo log 是InnoDB引擎特有的日志，而Server层也有属于自己的日志，我们称为：binlog（归档日志）
为什么会有两份日志呢？
因为最开始 MySQL 里并没有 InnoDB 引擎。MySQL 自带的引擎是 MyISAM，但是
MyISAM 没有 crash-safe 的能力，binlog 日志只能用于归档。而 InnoDB 是另一个公司
以插件形式引入 MySQL 的，既然只依靠 binlog 是没有 crash-safe 能力的，所以
InnoDB 使用另外一套日志系统——也就是 redo log 来实现 crash-safe 能力。
这两种日志有以下三点不同。
1. redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。
2. redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日
志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ”。
3. redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指
binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
有了对这两个日志的概念性理解，我们再来看执行器和 InnoDB 引擎在执行这个简单的
update 语句时的内部流程。
你可能注意到了，最后三步看上去有点“绕”，将 redo log 的写入拆成了两个步骤：
prepare 和 commit，这就是"两阶段提交"。
第一阶段(prepare)：
首先，协调者在自身节点的日志中写入一条的日志记录，然后所有参与者发送消息prepare T，询问这些参与者（包括自身），是否能够提交这个事务.
参与者在接受到这个prepare T 消息以后，会根据自身的情况，进行事务的预处理，如果参与者能够提交该事务，则会将日志写入磁盘，并返回给协调者一个ready T信息，同时自身进入预提交状态状态；如果不能提交该事务，则记录日志，并返回一个not commit T信息给协调者，同时撤销在自身上所做的数据库改；参与者能够推迟发送响应的时间，但最终还是需要发送的。
第二阶段(commit)：
协调者会收集所有参与者的意见，如果收到参与者发来的not commit T信息，则标识着该事务不能提交，协调者会将Abort T (abort终止) 记录到日志中，并向所有参与者发送一个Abort T 信息，让所有参与者撤销在自身上所有的预操作；
如果协调者收到所有参与者发来prepare T信息，那么协调者会将Commit T日志写入磁盘，并向所有参与者发送一个Commit T信息，提交该事务。若协调者迟迟未收到某个参与者发来的信息，则认为该参与者发送了一个VOTE_ABORT信息，从而取消该事务的执行。
参与者接收到协调者发来的Abort T信息以后，参与者会终止提交，并将Abort T 记录到日志中；如果参与者收到的是Commit T信息，则会将事务进行提交，并写入记录。
一般情况下，两阶段提交机制都能较好的运行，当在事务进行过程中，有参与者宕机时，他重启以后，可以通过询问其他参与者或者协调者，从而知道这个事务到底提交了没有。当然，这一切的前提都是各个参与者在进行每一步操作时，都会事先写入日志。
那为什么需要使用两阶段提交呢？
1. 先写 redo log 后写 binlog。假设在 redo log 写完，binlog 还没有写完的时候，MySQL 进程异常重启。由于我们前面说过的，redo log 写完之后（redo log 写完之后，待程序空闲的时候，会把数据更新到磁盘的），系统即使崩溃，仍然能够把数据恢复回来，所以恢复后这一行 c 的值是 1。
但是由于 binlog 没写完就 crash 了，这时候 binlog 里面就没有记录这个语句。因此，之后备份日志的时候，存起来的 binlog 里面就没有这条语句。然后你会发现，如果需要用这个 binlog 来恢复临时库的话，由于这个语句的 binlog 丢失，这个临时库就会少了这一次更新，恢复出来的这一行 c 的值就是 0，与原库的值不同。
2. 先写 binlog 后写 redo log。如果在 binlog 写完之后 crash，由于 redo log（磁盘没有真正更新） 还没写，崩溃恢复以后这个事务无效，所以这一行 c 的值是 0。但是 binlog 里面已经记录了“把 c 从 0 改成 1”这个日志。所以，在之后用 binlog 来恢复的时候就多了一个事务出来，恢复出来的这一行 c 的值就是 1，与原库的值不同
