一条更新SQL 是如何执行的

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

在数据库里面，我们说的 update 操作其实包括了更新、插入和删除。更新流程和查询流程有什么不同呢？
基本流程也是一致的，也就是说，它也要经过解析器、优化器的处理，最后交给执行器。
区别就在于拿到符合条件的数据之后的操作。
首先，在 InnoDB 里面有个内存的缓冲池（buffer pool）。我们对数据的更新，不会每次都直接写到磁盘上，因为 IO 的代价太大了，所以先写入到 buffer pool 里面。内存的数据页和磁盘数据不一致的时候，我们把它叫做脏页。
InnoDB 里面有专门的把 buffer pool 的数据写入到磁盘的线程，每隔一段时间就一次性地把多个修改写入磁盘，这个就叫做刷脏。

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

redo log

InnoDB 引入了一个日志文件，叫做 redo log（重做日志），我们把所有对内存数据的修改操作写入日志文件，如果服务器出问题了，我们就从这个日志文件里面读取数据，恢复数据——用它来实现事务的持久性。
特点：
1.记录修改后的值，属于物理日志
2.redo log 的大小是固定的，前面的内容会被覆盖，所以不能用于数据回滚/数据恢复。
3.redo log 是 InnoDB 存储引擎实现的，并不是所有存储引擎都有。

binlog

MySQL Server 层也有一个日志文件，叫做 binlog，它可以被所有的存储引擎使用。
binlog 以事件的形式记录了所有的 DDL 和 DML 语句（因为它记录的是操作而不是数据值，属于逻辑日志），可以用来做主从复制和数据恢复。

主从复制

数据恢复

binlog它的文件内容是可以追加的，没有固定大小限制

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

例如一条语句：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。简单地来说，这里有两个写日志的操作，类似于分布式事务，不用两阶段提交，就不能保证都成功或者都失败