说到mysql的数据的日志系统，我们必须先说说MySQL的执行流程：

mysql查询链路

上图就是我简单的画了一个sql执行流程，不做细讲了，详细的可以听一下极客实践的mysql精讲45。

更新sql和查询sql不同的是

和查询sql的是流程上我们的update还需要经过日志板块：redolog 和binlog

什么是redolog （重做日志）

这个日志是innodb的独有日志模块，那应该怎么理解这个东西的运行机制呢：
假设一个场景：你是酒店老板，很多人来吃饭，有人赊账，有人还账。
而你有 ：一个账本（只记录结算金额，每人一条），一个小黑板

解决方法一：不用小黑板，每次直接查找账本，加上本次赊账/还款，计算最终结果重新写入账本
解决方法二：每次写入小黑板，等人少了或者写满了，直接计算写入账本
很明显我们第二种方式是最方便的，也是最不容易出错的

所以我们的redolog就是跟新的时候的小黑板，它的运行机制： redolog作用图(1).png

这里也是一个专业名词，我们面试的时候也可能出现：WAL（write-Ahead Logging）

Crash-safe

但是这里可能就有一个问题：

小黑板写满了怎么办？？？？：和人一样，小黑板在人流量多的时候会出现写满的时候
（一般不会出现，redolog分配内存足够大），那么只能暂停一切写入操作，
把小黑板的计算写入账本后才能继续写入，所以老板会先算完帐后再进行新的收账。
但是这里我们就要聊到一个概念叫做crash-safe，也就是这里还有一个专门计算的伙计
，老板一边记录，这边有个小伙子计算并擦除掉计算好了的记录，并保存到账本上去，
速度上肯定是老板写入要快的多，但是这样下来不至于导致整个黑板快速的写满，基本上就是
老板一边写，伙计一边算，写满后，要停一段时间等伙计。

Binlog

这个是mysql的server上层，所谓的server上层就是：连接器+分析器+优化器+执行器的总和，但是具体操作还是在执行器中。只要知道有mysql就可以使用binlog。这个也是我们的搭建主从架构的重要一环，我们的数据恢复也是从这里开始的。如果误删除了一个表，我们找到对应的最近的备份时间点，进行Binlog的重放

Binlog和Redo log 的执行先后顺序

以上我们知道了Binlog 和redolog 是两个的日志系统，那么到底mysql是先写binlog 还是redolog呢，或者说他们zan边。
那么我们必须知道修改一条数据我们的mysql进行了哪些步骤。加入我们有下面有一条sql

update T set a=a+1 where ID=1

那么在这里binlog和redolog是怎么运作的呢，具体的运行地方是：执行器和引擎。binlog是在执行器中，redolog是在引擎中。

两阶段提交

可以从我画的这个图来看我们可以知道以下东西
1.先写的是redolog ，然后才是binlog
2.redlog和binlog 一定是一致的，因为有个事务来管理这个修改的一致性
3.redlog在提交的时候有两个阶段：prepare和commit

两阶段提交

什么是两阶段提交：就是指redolog的prepare和coomit两个阶段，可以看下上图。那么为什么需要这个两个阶段提交来保证两个日志的一致性呢？

假设我们写入binlog时出现了crash了，那么我们的redolog还有crash-safe策略，假设a本来=1，然后我们这里redolog里面a=2了，而我们的binlog还是等于1，此时我们还没有已经产生分歧但是呢还没造成数据冲突，但是我们的操作流程时怎么的，掌柜（innodb）会将redolog的数据写进磁盘，此时数据库内的数据a=2，但是日志binlog还是=1，此时就有毛病了，为什么？因为主从复制，binlog被复制到从库去，数据主库时a=2，从库数据数据是a=2。

所以两阶段提交的原因是：保证数据的一致性

以上就是我们的mysql的更新数据的链路，与君共勉
转载请标明出处