在上一篇《面试官：你说说一条查问SQL的执行过程？》中形容了Mysql的架构分层，通过解析器、优化器和执行引擎实现一条SQL查问的过程，那这一篇续上持续阐明一条更新SQL的执行过程。
对于一个SQL语句的更新来说，后面的流程都能够说相似的，通过解析器进行语法分析，优化器优化，执行引擎去执行，这个都没有什么问题，重点在于多了一点货色，那就是redo_log、undo_log和binlog。
执行流程大抵如下：
- 首先客户端发送申请到服务端，建设连贯。
- 服务端先看下查问缓存，对于更新某张表的SQL，该表的所有查问缓存都生效。
- 接着来到解析器，进行语法分析，一些零碎关键字校验，校验语法是否合规。
- 而后优化器进行SQL优化，比方怎么抉择索引之类，而后生成执行打算。
- 执行引擎去存储引擎查问须要更新的数据。
- 存储引擎判断以后缓冲池中是否存在须要更新的数据，存在就间接返回，否则去从磁盘加载数据。
- 执行引擎调用存储引擎API去更新数据。
- 存储引擎更新数据，同时写入undo_log、redo_log信息。
- 执行引擎写binlog，提交事务，流程完结。
能够看到相比于查问流程，实际上更新多了对于undo_log和redo_log的流程，接下来再具体探讨一下这几个流程的执行过程是什么样子。
redo_log
redo_log依照字面翻译称为重做日志，是InnoDB存储引擎特有的，用于保障事务的原子性和持久性。怎么了解呢？简略来说就是保留咱们执行的更新语句的记录，如果服务器或者Mysql宕机，通过redo_log能够复原更新的数据。
依照上述流程来举例的话，比方update user set age=20 where id=1这样的简略更新SQL，咱们不论执行引擎怎么拿到的数据，不论是从缓冲池拿的还是磁盘拿到的，这条当初数据都在缓冲池外面，而后去缓冲池的数据把age改成10。
缓冲池内存中的数据曾经更新好了，那么接下来就该开始写redo_log了，只是redo_log也不是间接写文件的，个别都是这样对吧，间接写的话性能太差了，所以就有redo_log_buffer叫做redo_log缓冲。
在写redo_log的时候先把数据写到redo_log缓冲区，而后异步写入磁盘，很显然，极其状况下会有失落数据的可能。
管制这个刷盘策略的的参数叫做innodb_flush_log_at_trx_commit。
这个参数有3个值：0|1|2，默认的话是1。
0代表提交事务时不会写入磁盘，这样的话性能当然最好，然而在Mysql宕机的状况会失落上一秒的事务的数据。
1代表提交事务肯定会进行一次刷盘，同步当然性能最差，然而也最平安。
2代表写入文件系统的缓存，不进行刷盘。这个选项性能略差于1，Mysql宕机的话对数据没有任何影响，只有在操作系统宕机才会失落数据，这种状况下默认Mysql每秒会执行一次刷盘。
应用0或者2尽管进步了性能，然而变相的也丢失了事务的持久性。
undo_log
重做日志保障了事务的持久性，保障可能在宕机后复原事务的数据，那么另外一种状况就是事务在须要回滚的时候怎么办？这时候就是undo_log的作用了，它保障了事务的一致性。
对于undo_log来说，简略了解就是做了逆向操作。
比方insert一条数据，就对应生成delete，update语句则生成相同的更新语句，这样做到将数据批改回之前的状态。
binlog
binlog称为二进制日志，大家都很相熟，记录了扭转数据库的那些SQL语句，对于这里来说，更新语句当然是了。
通过不同于redo_log是独属于存储引擎独有的货色，binlog则是Mysql自身产生的日志。
不同于redo_log是物理日志，binlog和undo_log都属于逻辑日志。
这有什么区别呢？
简略来说，逻辑日志能够认为就是存储的SQL自身，而物理日志看看redo_log存储的是啥就晓得了，对于page_id页ID，offset偏移量啊这些货色，记录的是对页的批改。
另外物理日志能够保障幂等性，而逻辑日志则不肯定能，除非自身SQL就是幂等的。
下面咱们提到了redo_log的刷盘策略，binlog就和它十分相似了，控制参数是sync_binlog。
默认值为0，相当于是innodb_flush_log_at_trx_commit的值为2，由文件系统管制，同样如果服务器宕机，binlog失落，当然咱们也能够改成1，就和redo_log的成果是一样，每1次事务提交都同步写入磁盘。
事务
为了保障写redo_log和binlog的一致性，理论采纳了二阶段提交的形式。
prepare阶段：依据innodb_flush_log_at_trx_commit设置的刷盘策略决定是否写入磁盘，标记为prepare状态。
commit阶段：写入binlog日志，事务标记为提交状态。