Mysql学习宝典（二） -- 从更新语句执行流程引出的Mysql各种日志

三、一条更新SQL 是如何执行的？

在数据库里面，我们说的 update 操作其实包括了更新、插入和删除。更新流程和查询流程有什么不同呢？

基本流程也是一致的，也就是说，它也要经过解析器、优化器的处理，最后交给执行器。

区别就在于拿到符合条件的数据之后的操作。

首先，在 InnoDB 里面有个内存的缓冲池（buffer pool）。我们对数据的更新，不会每次都直接写到磁盘上，因为 IO 的代价太大了，所以先写入到 buffer pool 里面。内存的数据页和磁盘数据不一致的时候，我们把它叫做脏页。

InnoDB 里面有专门的把 buffer pool 的数据写入到磁盘的线程，每隔一段时间就一次性地把多个修改写入磁盘，这个就叫做刷脏。

这里面就有一个问题，如果在脏页还没有写入磁盘的时候，服务器出问题了，内存里面的数据丢失了。或者是刷脏刷到一半，甚至会破坏数据文件。所以我们必须要有一个持久化的机制。

redo log

InnoDB 引入了一个日志文件，叫做 redo log（重做日志），我们把所有对内存数据的修改操作写入日志文件，如果服务器出问题了，我们就从这个日志文件里面读取数据，恢复数据——用它来实现事务的持久性。

redo log 有什么特点？

1.记录修改后的值，属于物理日志

2.redo log 的大小是固定的，前面的内容会被覆盖，所以不能用于数据回滚/数据恢复。

3.redo log 是 InnoDB 存储引擎实现的，并不是所有存储引擎都有。

binlog

MySQL Server 层也有一个日志文件，叫做 binlog，它可以被所有的存储引擎使用。

binlog 以事件的形式记录了所有的 DDL 和 DML 语句（因为它记录的是操作而不是数据值，属于逻辑日志），可以用来做主从复制和数据恢复。

主从复制

数据恢复

跟 redo log 不一样，它的文件内容是可以追加的，没有固定大小限制。

有了这两个日志之后，我们来看一下一条更新语句是怎么执行的：

例如一条语句：update teacher set name=‘jim’ where name =‘666’

1、先查询到这条数据，如果有缓存，也会用到缓存。

2、把 name 改成jim，然后调用引擎的 API 接口，写入这一行数据到内存，同时记录 redo log。这时 redo log 进入 prepare 状态，然后告诉执行器，执行完成了，可以随时提交。

3、执行器收到通知后记录 binlog，然后调用存储引擎接口，设置 redo log 为 commit 状态。

4、更新完成。

问题：为什么要用两阶段提交（XA）呢？

举例：

如果我们执行的是把 name 改成jim，如果写完 redo log，还没有写 bin log 的时候，MySQL 重启了。

因为 redo log 可以恢复数据，所以写入磁盘的是jim。但是 bin log 里面没有记录这个逻辑日志，所以这时候用 binlog 去恢复数据或者同步到从库，就会出现数据不一致的情况。

所以在写两个日志的情况下，binlog 就充当了一个事务的协调者。通知 InnoDB 来执行 prepare 或commit 或者 rollback。

简单地来说，这里有两个写日志的操作，类似于分布式事务，不用两阶段提交，就不能保证都成功

一个事务的协调者。通知 InnoDB 来执行 prepare 或commit 或者 rollback。

简单地来说，这里有两个写日志的操作，类似于分布式事务，不用两阶段提交，就不能保证都成功或者都失败。