为什么 需要 undo log ？
MySQL 日志：undo log 、redo log 、binlog 有什么 用？
从这篇「执行一条 SQL 查询语句，期间发生了什么 ？ 」中，我们知道了一条查 询语句经历的过
程，这属于「读」一条记录的过程，如下图：
那么，执行一条 update 语句，期间发生了什么 ？，比如这一条 update 语句：
UPDATE t_user SET name = 'xiaolin' WHERE id = 1;查询语句的那一套流程，更新语句也是同样会走一遍：
客⼾端先通过连 接器建立连接，连接器自会判断用⼾身份；
因为这是一条 update 语句，所以不需要经过查询缓存，但是表上有更 新语句，是会把整个表的
查询缓存清空的，所以说查询缓存很鸡肋，在 MySQL 8.0 就被移除这个功能了；
解析器会通过词法分析识别出 关键字 update ，表名等等 ，构建出语法树，接着还会做语法分
析，判断输入的语句是否符合 MySQL 语法；
预处理器会判断表和字段是否存在；
优化器确定执行计划，因为 where 条件中的 id 是主键索引，所以决定要使用 id 这个索引；
执行器负责 具体执行，找到这一行，然后更新。
不过，更新语句的流程会涉及到 undo log （回滚日志）、redo log （重做日志） 、binlog （归档日志）这三种日志：
undo log （回滚日志）：是 Innodb 存储引擎层生成的日志，实现了事 务中的原子性，主要用于事务回滚和 MVCC 。
redo log （重做日志）：是 Innodb 存储引擎层生成的日志，实现了事 务中的持久性，主要用于
掉电等故障恢复；
binlog （归档日志）：是 Server 层生成的日志，主要用于数据备份和主从 复制；
所以这次就带着这个问题，看看 这三种日志是怎么工作的。
为什么 需要 undo log ？
我们在执行执行一条“增删改”语句的时候，虽然没有输入 begin 开启事务和 commit 提交事 务，但
是 MySQL 会隐式开 启事务来执行“增删改”语句的，执行完就自动提交事 务的，这样就保证了执行
完“增删改”语句后，我们可以及时在数据库表看到“增删改”的结果了。
执行一条语句是否自动提交事 务，是由 autocommit 参数决定的，默认是开启。所以，执行一条
update 语句也是会使 用事务的。
那么，考虑一个问题。一个事 务在执行过程中，在还没有提交事 务之前，如果 MySQL 发生了崩
溃，要怎么回滚到事务之前的数据呢？
如果我们每次 在事务执行过程中，都记录下回滚时需要的信息到一个日志里，那么在事务执行中
途发生了 MySQL 崩溃后，就不用担心无法回滚到事务之前的数据，我们可以通过这 个日志回滚到
事务之前的数据。
实现这一机制就是 undo log （回滚日志），它保证了事 务的 ACID 特性 中的原子性（Atomicity ）。
undo log 是一种用于撤销回退的日志。在事务没提交之 前，MySQL 会先记录更新前的数据到
undo log 日志文件里面，当事务回滚时，可以利用 undo log 来进行回滚。如下图：
每当 InnoDB 引擎对一条记录进行操作（修改、删除、新增）时，要把回滚时需要的信息都记录到
undo log 里，比如：
在插入一条记录时，要把这条记录的主键值记下来，这样之后回滚时只需要把这个主 键值对应
的记录删掉就好了；
在删除一条记录时，要把这条记录中的内容都记下来，这样之后回滚时再把由这些内容组成的
记录插入到表中就好了；
在更新一条记录时，要把被更新的列的旧值记下来，这样之后回滚时再把这些列更新为旧值就
好了。
在发生回滚时，就读取 undo log 里的数据，然后做原先相反操作。比如当 delete 一条记录时，
undo log 中会把记录中的内容都记下来，然后执行回滚操作的时候，就读取 undo log 里的数据，
然后进行 insert 操作。
针对 delete 操作和 update 操作会 有一些特殊的处理：
delete 操作实际上不 会立即直接删除，而是将delete 对象打上delete flag ，标记为删除，最终的
删除操作是purge 线程完成的。
update 分为两 种情况：update 的列是否是主键列。
如果不是主键列，在undo log 中直接反向记录是如何update 的。即update 是直接进行的。
如果是主键列，update 分两部执行：先删除该行，再插入一行目标行。
不同的操作，需要记录的内容也是不同的，所以不同类型的操作（修改、删除、新增）产生的
undo log 的格式也是不同的，具体的每一个操作的 undo log 的格式我就不详细介绍了，感兴趣的
可以自己去查查 。
一条记录的每一次更新操作产生的 undo log 格式都有一个 roll_pointer 指针和一个 trx_id 事务id ：
通过 trx_id 可以知道该记 录是被哪个事 务修改的；通过 roll_pointer 指针可以将这些 undo log 串成一个链表，这个链表就被称为版本链；
版本链如下图：
另外，undo log 还有一个作用，通过 ReadView + undo log 实现 MVCC （多版本并发控制）。
对于「读提交」和「可重复读」隔离级别的事务来说，它们的快照读（普通 select 语句）是通过
Read View + undo log 来实现的，它们的区别在于创建 Read View 的时机不同：
「读提交」隔离级别是在每个 select 都会生成一个新的 Read View ，也意味着，事务期间的多
次读取同一条数据，前后两次读的数据可能会出现不一致，因为可能这期间另外一个事 务修改
了该记 录，并提交了事 务。
「可重复读」隔离级别是启动事务时生成一个 Read View ，然后整个事 务期间都在用这个 Read View ，这样就保证了在事务期间读到的数据都是事务启动前 的记录。
这两个 隔离级别实现是通过「事务的 Read View 里的字段」和「记录中的两个 隐藏列（trx_id 和
roll_pointer ）」的比对，如果不满足可⻅行，就会顺着 undo log 版本链里找到满足其可⻅性的记
录，从而控制并发事务访问同一个记录时的行为，这就叫 MVCC （多版本并发控制）。具体的实现
可以看我这篇文章：事务隔离级别是怎么实现的？
因此，undo log 两大作用：
实现事务回滚，保障事务的原子性。事务处理过程中，如果出现了错误或者用⼾执 行了
ROLLBACK 语句，MySQL 可以利用 undo log 中的历史数据将数据恢复到事务开始之前的状
态。
实现 MVCC （多版本并发控制）关键因素之一。MVCC 是通过 ReadView + undo log 实现的。
undo log 为每条记录保存多份历史数据，MySQL 在执行快照读（普通 select 语句）的时候，
会根据事务的 Read View 里的信息，顺着 undo log 的版本链找到满足其可⻅性的记录。
TIP
很多人疑问 undo log 是如何刷盘（持久化到磁盘）的？
undo log 和数据⻚的刷盘策略是一样的，都需要通过 redo log 保证持久化。
buffer pool 中有 undo ⻚，对 undo ⻚的修改也都会记录到 redo log 。redo log 会每秒刷
盘，提交事 务时也会刷盘，数据⻚和 undo ⻚都是靠这个机制保证持久化的。
为什么 需要 Buffer Pool ？
MySQL 的数据都是存在磁盘中的，那么我们要更新一条记录的时候，得先要从磁盘读取该记 录，
然后在内存中修改这条记录。那修改完这条记录是选择直接写回到磁盘，还是选择缓存起来呢？
当然是缓存起来好，这样下次有查 询语句命中了 这条记录，直接读取缓存中的记录，就不需要从
磁盘获取数据了。
为此，Innodb 存储引擎设计 了一个缓冲池（Buffer Pool ），来提高数据库的读写性能。
有了 Buffer Poo 后：
当读取数据时，如果数据存在于 Buffer Pool 中，客⼾端就会直接读取 Buffer Pool 中的数据，
否则再去磁盘中读取。
当修改数 据时，如果数据存在于 Buffer Pool 中，那直接修改 Buffer Pool 中数据所在的⻚，然
后将其⻚设置为脏⻚（该⻚的内存数据和磁盘上的数据已经不一致），为了 减少磁盘I/O ，不会
立即将脏⻚写入磁盘，后续由后台 线程选择一个合适的时机将脏⻚写入到磁盘。
Buffer Pool 缓存什么 ？
InnoDB 会把存储的数据划分 为若干个「⻚」，以⻚作为磁盘和内存交互 的基本单位，一个⻚的默
认大小为 16KB 。因此，Buffer Pool 同样需要按「⻚」来划分 。
在 MySQL 启动的时候，InnoDB 会为 Buffer Pool 申请一片连续的内存空间，然后按照默认的
16KB 的大小划分出 一个个 的⻚， Buffer Pool 中的⻚就叫做缓存⻚。此时这些缓存⻚都是空闲
的，之后随着程序的运行，才会有磁盘上的⻚被缓存到 Buffer Pool 中。
所以，MySQL 刚启动的时候，你会 观察到使用的虚拟内存空间很大，而使用到的物理内存空间却
很小，这是因为只有这些虚拟内存被访问后，操作系统才会触发缺⻚中断，申请物理内存，接着
将虚拟地址 和物理地址 建立映射关系。
Buffer Pool 除了缓存「索引⻚」和「数据⻚」，还包括了 Undo ⻚，插入缓存、自适应哈希索引、
锁信息等等 。
Undo ⻚是记录什么 ？
开启事务后，InnoDB 层更新记录前，首先要记录相应的 undo log ，如果是更新操作，需要把被更
新的列的旧值记下来，也就是要生成一条 undo log ，undo log 会写入 Buffer Pool 中的 Undo ⻚ 面。
查询一条记录，就只需要缓冲一条记录吗？
不是的。
当我们查询一条记录时，InnoDB 是会把整个⻚的数据加载到 Buffer Pool 中，将⻚加载到 Buffer Pool 后，再通过⻚里的「⻚目录」去定位到某条 具体的记录。
关于⻚结构⻓什么 样和索引怎么查询数据的问题可以在这篇找到答案：换一个⻆度看 B+ 树
为什么 需要 redo log ？
Buffer Pool 是提高了读写效率没错，但是问题来了，Buffer Pool 是基于内存的，而内存总是不可
靠，万一断电重启，还没来得及落盘的 脏⻚数据就会丢失。
为了 防止断电导致数据丢失的问题，当有一条记录需要更新的时候，InnoDB 引擎就会先更新内存
（同时标记为脏⻚），然后将本次对这个⻚的修改以 redo log 的形式 记录下来，这个时候更新就算
完成了。
后续，InnoDB 引擎会在适当的时候，由后台 线程将缓存在 Buffer Pool 的脏⻚刷新到磁盘里，这就
是 WAL （Write-Ahead Logging ）技术。
WAL 技术指的是， MySQL 的写操作并不是立刻写到磁盘上，而是先写 日志，然后在合适的时间
再写 到磁盘上。
过程如下图：
什么 是 redo log ？
redo log 是物理日志，记录了某个数据⻚做了什么 修改，比如对 XXX 表空间中的 YYY 数据⻚ ZZZ
偏移量的地方做了AAA 更新，每当执行一个事 务就会产生这样的一条或者多条物理日志。
在事务提交时，只要先将 redo log 持久化到磁盘即可，可以不需要等到将缓存在 Buffer Pool 里的
脏⻚数据持 久化到磁盘。
当系统崩溃时，虽然脏⻚数据没有持久化，但是 redo log 已经持久化，接着 MySQL 重启后 ，可
以根据 redo log 的内容，将所有数据恢复到最新的状态。
被修改 Undo ⻚面，需要记录对应 redo log 吗？
需要的。
开启事务后，InnoDB 层更新记录前，首先要记录相应的 undo log ，如果是更新操作，需要把被更
新的列的旧值记下来，也就是要生成一条 undo log ，undo log 会写入 Buffer Pool 中的 Undo ⻚
面。
不过，在内存修改该 Undo ⻚面后，也是需要记录对应的 redo log ，因为undo log 也要实现持久
性的保护。
redo log 和 undo log 区别在哪？
这两种日志是属于 InnoDB 存储引擎的日志，它们的区别在于：
redo log 记录了此次 事务「修改后」的数据状态，记录的是更新之后的值，主要用于事 务崩溃
恢复，保证事务的持久性。
undo log 记录了此次 事务「修改前」的数据状态，记录的是更新之前的值，主要用于事 务回
滚，保证事务的原子性。
事务提交之 前发生了崩溃（这里的崩溃不是宕机崩溃，而是事务执行错误，mysql 还是正常运行
的。如果是宕机崩溃的话，其实就不需要通过 undo log 回滚了，因为事 务没有提交，事务的数据
并不会持久化，还是在内存中，宕机崩溃了数据就丢失了，反正事务都没有提交成功，所以数据
本身就无意义的，丢失了就丢失了），重启后 会通过 undo log 回滚事务。
事务提交之 后发生了崩溃（这里的崩溃是宕机崩溃），重启后 会通过 redo log 恢复事务，如下图：
所以有了 redo log ，再通过 WAL 技术，InnoDB 就可以保 证即使数据库发生异常重启，之前已提
交的记录都不会丢失，这个能力称为 crash-safe （崩溃恢复）。可以看出来， redo log 保证了事 务
四大特性中的持久性。
redo log 要写到磁盘，数据也要写磁盘，为什么 要多此一举？
写入 redo log 的方式使用了追加操作， 所以磁盘操作是顺序写，而写入数据需要先找到写入位
置，然后才写到磁盘，所以磁盘操作是随机写。
磁盘的 「顺序写 」比「随机写」 高效的多，因此 redo log 写入磁盘的 开销更小。
针对「顺序写」为什么 比「随机写」更快这个问题，可以比喻为你有一个本子，按照顺序一⻚一
⻚写肯定比写一个字都要找到对应⻚写快得 多。
可以说这是 WAL 技术的另外一个优点：MySQL 的写操作从磁盘的 「随机写」变成了「顺序写」，
提升语句的执行性能。这是因为 MySQL 的写操作并不是立刻更新到磁盘上，而是先记录在日志
上，然后在合适的时间再更新到磁盘上 。
至此， 针对为什么 需要 redo log 这个问题我们有两个 答案：
实现事务的持久性，让 MySQL 有 crash-safe 的能力，能够保证 MySQL 在任何 时间段突然崩
溃，重启后 之前已提交的记录都不会丢失；
将写操作从「随机写」变成了「顺序写」，提升 MySQL 写入磁盘的 性能。
产生的 redo log 是直接写入磁盘的 吗？
不是的。
实际上， 执行一个事 务的过程中，产生的 redo log 也不 是直接写入磁盘的 ，因为这样会产生大量
的 I/O 操作，而且磁盘的 运行速度远慢于内存。
所以，redo log 也有自己的缓存—— redo log buffer ，每当产生一条 redo log 时，会先写 入到
redo log buffer ，后续在持久化到磁盘如下图：
redo log buffer 默认大小 16 MB ，可以通过 innodb_log_Buffer_size 参数动态的调整大小，增大它的大小可以让 MySQL 处理「大事务」是不必写入磁盘，进而提升写 IO 性能。
redo log 什么 时候刷盘？
缓存在 redo log buffer 里的 redo log 还是在内存中，它什么 时候刷新到磁盘？
主要有下面几个时机：
MySQL 正常关闭时；
当 redo log buffer 中记录的写入量大于 redo log buffer 内存空间的一半时，会触发落盘；
InnoDB 的后台 线程每隔 1 秒，将 redo log buffer 持久化到磁盘。
每次 事务提交时都将缓存在 redo log buffer 里的 redo log 直接持 久化到磁盘（这个策略可由
innodb_flush_log_at_trx_commit 参数控制，下面会说）。
innodb_flush_log_at_trx_commit 参数控制的是什么 ？单独执行一个更新语句的时候，InnoDB 引擎会自己启动一个事 务，在执行更新语句的过程中，生
成的 redo log 先写 入到 redo log buffer 中，然后等事务提交的时候，再将缓存在 redo log buffer
中的 redo log 按组的方式「顺序写」到磁盘。
上面这种 redo log 刷盘时机是在事务提交的时候，这个默认的行为。
除此之外，InnoDB 还提供了另外两种策略，由参数 innodb_flush_log_at_trx_commit 参数控制，可取的值有：0、1、2，默认值为 1，这三个 值分别 代表的策略如下：
当设置该参数为 0 时，表示每次 事务提交时 ，还是将 redo log 留在 redo log buffer 中 ，该模
式下在事务提交时不会主动触发写入磁盘的 操作。
当设置该参数为 1 时，表示每次 事务提交时，都将缓存在 redo log buffer 里的 redo log 直接持久化到磁盘，这样可以保 证 MySQL 异常重启之后数据不会丢失。
当设置该参数为 2 时，表示每次 事务提交时，都只是缓存在 redo log buffer 里的 redo log 写到
redo log 文件，注意写入到「 redo log 文件」并不意味着写入到了磁盘，因为操作系统的文件
系统中有个 Page Cache （如果你想了解 Page Cache ，可以看这篇 ），Page Cache 是专⻔用
来缓存文件数据的，所以写入「 redo log 文件」意味着写入到了操作系统的文件缓存。
我画了一个图，方便大家理解：
innodb_flush_log_at_trx_commit 为 0 和 2 的时候，什么 时候才将 redo log 写入磁盘？InnoDB 的后台 线程每隔 1 秒：
针对参数 0 ：会把缓存在 redo log buffer 中的 redo log ，通过调用 write() 写到操作系统的
Page Cache ，然后调用 fsync() 持久化到磁盘。所以参数为 0 的策略，MySQL 进程的崩溃会
导致上一秒钟所有事务数据的丢失;针对参数 2 ：调用 fsync ，将缓存在操作系统中 Page Cache 里的 redo log 持久化到磁盘。所以
参数为 2 的策略，较取值为 0 情况下更安全，因为 MySQL 进程的崩溃并不会丢失数据，只有
在操作系统崩溃或者系统断电的情况下，上一秒钟所有事务数据才可能丢失。
加入了后台 现线程后，innodb_flush_log_at_trx_commit 的刷盘时机如下图：这三个 参数的应用场景是 什么 ？
这三个 参数的数据安全性和写入性能的比较如下：
数据安全性：参数 1 > 参数 2 > 参数 0
写入性能：参数 0 > 参数 2> 参数 1
所以，数据安全性和写入性能是熊掌不可得兼的，要不追求数据安全性，牺牲 性能；要不追求性
能，牺牲 数据安全性。
在一些对数据安全性要求比较高的场景中，显然 innodb_flush_log_at_trx_commit 参数需要设置为 1。
在一些可以容忍数据库崩溃时丢失 1s 数据的场景中，我们可以将该值设置为 0，这样可以明显
地减少日志同步到磁盘的 I/O 操作。
安全性和性能折中的方案就是参数 2，虽然参数 2 没有参数 0 的性能高，但是数据安全性方面
比参数 0 强，因为参数 2 只要操作系统不宕机，即使数据库崩溃了，也不 会丢失数据，同时性
能方便比参数 1 高。
redo log 文件写满了怎么办？
默认情况下， InnoDB 存储引擎有 1 个重做日志文件组( redo log Group ），「重做日志文件组」由有 2 个 redo log 文件组成，这两个 redo 日志的文件名叫 ： ib_logfile0 和 ib_logfile1 。
在重做日志组中，每个 redo log File 的大小是固定且一致的，假设每个 redo log File 设置的上限
是 1 GB ，那么总共就可以记录 2GB 的操作。
重做日志文件组是以循环写的方式工作的，从头开始写，写到末尾就 又回到开头，相当于一个环
形。
所以 InnoDB 存储引擎会先写 ib_logfile0 文件，当 ib_logfile0 文件被写满的时候，会切换至
ib_logfile1 文件，当 ib_logfile1 文件也被写满时，会切换回 ib_logfile0 文件。
我们知道 redo log 是为了 防止 Buffer Pool 中的脏⻚丢失而设计 的，那么如果随着系统运行，
Buffer Pool 的脏⻚刷新到了磁盘中，那么 redo log 对应的记录也就没用了，这时候我们擦除这些
旧记录，以腾出空间记录新的更新操作。
redo log 是循环写的方式，相当于一个环形，InnoDB 用 write pos 表示 redo log 当前记录写到的
位置，用 checkpoint 表示当前要擦除的位置，如下图：
图中的：
write pos 和 checkpoint 的移动都是顺时针方向；
write pos 〜 checkpoint 之间的部分（图中的红色部分），用来记录新的更新操作；
check point 〜 write pos 之间的部分（图中蓝色部分）：待落盘的 脏数据⻚记录；
如果 write pos 追上了 checkpoint ，就意味着 redo log 文件满了，这时 MySQL 不能再执行新的更
新操作，也就是说 MySQL 会被阻塞（因此所以针对并发量大的系统，适当设置 redo log 的文件大
小非常重要），此时会停下来将 Buffer Pool 中的脏⻚刷新到磁盘中，然后标记 redo log 哪些记录
可以被擦除，接着对旧的 redo log 记录进行擦除，等擦除完旧记录腾出了空间，checkpoint 就会
往后移动（图中顺时针），然后 MySQL 恢复正常运行，继续执行新的更新操作。
所以，一次 checkpoint 的过程就是脏⻚刷新到磁盘中变成干净⻚，然后标记 redo log 哪些记录可
以被覆盖的 过程。
为什么 需要 binlog ？
前面介绍的 undo log 和 redo log 这两个 日志都是 Innodb 存储引擎生成的。
MySQL 在完成一条更 新操作后，Server 层还会生成一条 binlog ，等之后事务提交的时候，会将该
事物执行过程中产 生的所有 binlog 统一写 入 binlog 文件。
binlog 文件是记录了所有数据库表结构变更和表数据修改的日志，不会记录查询类的操作，比如
SELECT 和 SHOW 操作。
为什么 有了 binlog ， 还要有 redo log ？
这个问题跟 MySQL 的时间线有关系。
最开始 MySQL 里并没有 InnoDB 引擎，MySQL 自带的引擎是 MyISAM ，但是 MyISAM 没有
crash-safe 的能力，binlog 日志只能用于归档。
而 InnoDB 是另一个公司以插件形式引 入 MySQL 的，既然只依靠 binlog 是没有 crash-safe 能力
的，所以 InnoDB 使用 redo log 来实现 crash-safe 能力。
redo log 和 binlog 有什么 区别？
这两个 日志有四个区别。
1、适用对象不同：
binlog 是 MySQL 的 Server 层实现的日志，所有存储引擎都可以使 用；
redo log 是 Innodb 存储引擎实现的日志；
2、文件格式不同：
binlog 有 3 种格式类型，分别 是 STATEMENT （默认格式）、ROW 、 MIXED ，区别如下：
STATEMENT ：每一条修改数 据的 SQL 都会被记录到 binlog 中（相当于记录了逻辑操作，所
以针对这种格式， binlog 可以称为逻辑日志），主从 复制中 slave 端再根据 SQL 语句重现。
但 STATEMENT 有动态函数的问题，比如你用了 uuid 或者 now 这些函数，你在主库上执行
的结果并不是你在从库执行的结果，这种随时在变的函数会导致复制的数据不一致；
ROW ：记录行数据最终被修改成什么 样了（这种格式的日志，就不能称为逻辑日志了），不
会出现 STATEMENT 下动态函数的问题。但 ROW 的缺点是每行数据的变化 结果都会被记
录，比如执行批量 update 语句，更新多少行数据就会产生多少条记录，使 binlog 文件过
大，而在 STATEMENT 格式下只会记录一个 update 语句而已；
MIXED ：包含了 STATEMENT 和 ROW 模式，它会根据不同的情况自动使用 ROW 模式和
STATEMENT 模式；
redo log 是物理日志，记录的是在某个数据⻚做了什么 修改，比如对 XXX 表空间中的 YYY 数据
⻚ ZZZ 偏移量的地方做了AAA 更新；
3、写入方式不同：
binlog 是追加写，写满一个文件，就创建一个新的文件继续写，不会覆盖以前的日志，保存的
是全量的日志。
redo log 是循环写，日志空间大小是固定，全部写满就从头开始，保存未被刷入磁盘的 脏⻚日
志。
4、用途不同：
binlog 用于备份恢复、主从 复制；
redo log 用于掉电等故障恢复。
如果不小心整个数据库的数据被删除了，能使用 redo log 文件恢复数据吗？
不可以使 用 redo log 文件恢复，只能使用 binlog 文件恢复。
因为 redo log 文件是循环写，是会边写边擦除日志的，只记录未被刷入磁盘的 数据的物理日志，
已经刷入磁盘的 数据都会从 redo log 文件里擦除。
binlog 文件保 存的是全量的日志，也就是保存了所有数据变更的情况，理论上只要记录在 binlog
上的数据，都可以恢复，所以如果不小心整个数据库的数据被删除了，得用 binlog 文件恢复数
据。
主从 复制是怎么实现？
MySQL 的主从 复制依赖于 binlog ，也就是记录 MySQL 上的所有变化 并以二进制形式 保存在磁盘
上。复制的过程就是将 binlog 中的数据从主 库传输到从库上。
这个过程一般是异步的，也就是主库上执行事务操作的线程不会等待复制 binlog 的线程同步完
成。
MySQL 集群的主从 复制过程梳理成 3 个阶段：
写入 Binlog ：主库写 binlog 日志，提交事 务，并更新本地存储数据。
同步 Binlog ：把 binlog 复制到 所有从库上，每个从 库把 binlog 写到暂存日志中。
回放 Binlog ：回放 binlog ，并更新存储引擎中的数据。
具体详细过程如下：
MySQL 主库在收到客⼾端提交事 务的请求之后，会先写 入 binlog ，再提交事 务，更新存储引擎
中的数据，事务提交完成后，返回给客⼾端“操作成功”的响应。
从库会创建一个专 ⻔的 I/O 线程，连接主库的 log dump 线程，来接收主库的 binlog 日志，再
把 binlog 信息写入 relay log 的中继日志里，再返回给主库“复制成功”的响应。
从库会创建一个用于回放 binlog 的线程，去读 relay log 中继日志，然后回放 binlog 更新存储
引擎中的数据，最终实现主从 的数据一致性。
在完成主从 复制之后，你就可以在写数据时只写主库，在读数据时只读从库，这样即使写请求会
锁表或者锁记录，也不 会影响读请 求的执行。
从库是不是越多越好？
不是的。
因为从 库数量增加，从库连接上来的 I/O 线程也比较多，主库也要创建同样多的 log dump 线程来
处理复制的请求，对主库资源消耗比较高，同时还受限于主 库的网络带宽。
所以在实际使用中，一个主 库一般跟 2〜3 个从 库（1 套数据库，1 主 2 从 1 备主），这就是一主多
从的 MySQL 集群结构。
MySQL 主从 复制还有哪些模型？
主要有三种：
同步复制：MySQL 主库提交事 务的线程要等待所有从库的复制成功响应，才返回客⼾端结果。
这种方式在实际项目中，基本上没法 用，原因有两个 ：一是性能很差，因为要复制到 所有节点
才返回响应；二是可用性也很差，主库和所有从库任何 一个数据库出问题，都会影响业务。
异步复制（默认模型）：MySQL 主库提交事 务的线程并不会等待 binlog 同步到各从库，就返回
客⼾端结果。这种模式一旦主库宕机，数据就会发生丢失。
半同步复制：MySQL 5.7 版本之后增加的一种复制方式，介于两 者之间，事务线程不用等待所
有的从库复制成功响应，只要一部分复制成功响应回来就行，比如一主二从的集群，只要数据
成功复制到 任意一个从 库上，主库的事务线程就可以返回给客⼾端。这种半同步复制的方式，
兼顾了异步复制和同 步复制的优点，即使出现主库宕机，至少还有一个从 库有最 新的数据，不
存在数据丢失的⻛险。
binlog 什么 时候刷盘？
事务执行过程中，先把日志写到 binlog cache （Server 层的 cache ），事务提交的时候，再把
binlog cache 写到 binlog 文件中。
一个事 务的 binlog 是不能被拆开的，因此无论这个事 务有多大（比如有很多条语句），也要保证一
次性写入。这是因为有一个线程只能同时有一个事 务在执行的设定，所以每当执行一个
begin/start transaction 的时候，就会默认提交上 一个事 务，这样如果一个事 务的 binlog 被拆开的时候，在备库执行就会被当做多个事 务分 段自行，这样破坏了原子性，是有问题的。
MySQL 给每个线程分配了一片内存用于缓冲 binlog ，该内存叫 binlog cache ，参数binlog_cache_size 用于控制单个线程内 binlog cache 所占内存的大小。如果超过了这个参数规定的大小，就要暂存到磁盘。
什么 时候 binlog cache 会写到 binlog 文件？
在事务提交的时候，执行器把 binlog cache 里的完整事务写入到 binlog 文件中，并清空 binlog cache 。如下图：
虽然每个线程有自己 binlog cache ，但是最终都写到同一个 binlog 文件：
图中的 write ，指的就是指把日志写入到 binlog 文件，但是并没有把数据持 久化到磁盘，因为
数据还缓存在文件系统的 page cache 里，write 的写入速度还是比较快的，因为不 涉及磁盘
I/O 。
图中的 fsync ，才是将数据持 久化到磁盘的 操作，这里就会涉及磁盘 I/O ，所以频繁的 fsync 会
导致磁盘的 I/O 升高。
MySQL 提供一个 sync_binlog 参数来控制数据库的 binlog 刷到 磁盘上的频率：
sync_binlog = 0 的时候，表示每次 提交事 务都只 write ，不 fsync ，后续交由操作系统决定何时将数据持 久化到磁盘；
sync_binlog = 1 的时候，表示每次 提交事 务都会 write ，然后⻢上执行 fsync ；
sync_binlog =N(N>1) 的时候，表示每次 提交事 务都 write ，但累积 N 个事 务后才 fsync 。
在MySQL 中系统默认的设置是 sync_binlog = 0 ，也就是不做任何 强制性的磁盘刷新指令，这时候的性能是最好的，但是⻛险也是最大的。因为一旦主机发生异常重启，还没持久化到磁盘的 数据
就会丢失。
而当 sync_binlog 设置为 1 的时候，是最安全但是性能损耗最大的设置。因为当设置为 1 的时候，
即使主机发生异常重启，最多丢失一个事 务的 binlog ，而已经持久化到磁盘的 数据就不会有影
响，不过就是对写入性能影响太大。
如果能容少量事务的 binlog 日志丢失的⻛险，为了 提高写入的性能，一般会 sync_binlog 设置为
100~1000 中的某个数值。
三个 日志讲完了，至此我们可以先小结下，update 语句的执行过程。
当优化器分析出成本最 小的执行计划后，执行器就按照执行计划开始进行更新操作。
具体更新一条记录 UPDATE t_user SET name = 'xiaolin' WHERE id = 1; 的流程如下:
1. 执行器负责 具体执行，会调用存储引擎的接口，通过主键索引树搜索获取 id = 1 这一行记录：
如果 id=1 这一行所在的数据⻚本来 就在 buffer pool 中，就直接返回给执行器更新；如果记录不在 buffer pool ，将数据⻚从磁盘读入到 buffer pool ，返回记录给执行器。
- 执行器得到聚簇索引记录后，会看一下更新前的记录和更新后的记录是否一样：
如果一样的话就不进行后续更新流程；
如果不一样的话就把更新前的记录和更新后的记录都当作参数传给 InnoDB 层，让 InnoDB
真正的执行更新记录的操作；
- 开启事务， InnoDB 层更新记录前，首先要记录相应的 undo log ，因为这是更新操作，需要把
被更新的列的旧值记下来，也就是要生成一条 undo log ，undo log 会写入 Buffer Pool 中的
Undo ⻚面，不过在内存修改该 Undo ⻚面后，需要记录对应的 redo log 。
- InnoDB 层开始更新记录，会先更新内存（同时标记为脏⻚），然后将记录写到 redo log 里面，
这个时候更新就算完成了。为了 减少磁盘I/O ，不会立即将脏⻚写入磁盘，后续由后台 线程选择
一个合适的时机将脏⻚写入到磁盘。这就是 WAL 技术，MySQL 的写操作并不是立刻写到磁盘
上，而是先写 redo 日志，然后在合适的时间再将修改的行数据写到磁盘上。
至此，一条记录更新完了。
在一条更 新语句执行完成后，然后开始记录该语句对应的 binlog ，此时记录的 binlog 会被保存
到 binlog cache ，并没有刷新到硬盘上的 binlog 文件，在事务提交时才会统一将该事务运行过
程中的所有 binlog 刷新到硬盘。
- 事务提交，剩下的就是「两阶段提交」的事情了，接下来就讲这个。
为什么 需要两阶段提交？
事务提交后，redo log 和 binlog 都要持久化到磁盘，但是这两个 是独立的逻辑，可能出现半成功
的状态，这样就造成两份日志之间的逻辑不一致。
举个 例子，假设 id = 1 这行数据的字段 name 的值原本是 'jay' ，然后执行 UPDATE t_user SET
name = 'xiaolin' WHERE id = 1; 如果在持久化 redo log 和 binlog 两个 日志的过程中，出现了半成功状态，那么就有两种情况：
如果在将 redo log 刷入到磁盘之后， MySQL 突然宕机了，而 binlog 还没有来 得及写入。
MySQL 重启后 ，通过 redo log 能将 Buffer Pool 中 id = 1 这行数据的 name 字段恢复到新值xiaolin ，但是 binlog 里面没有记录这条更 新语句，在主从 架构 中，binlog 会被复制到 从库，由
于 binlog 丢失了这条更 新语句，从库的这一行 name 字段是旧值 jay ，与主 库的值不一致性；
如果在将 binlog 刷入到磁盘之后， MySQL 突然宕机了，而 redo log 还没有来 得及写入。由于
redo log 还没写，崩溃恢复以后这个事 务无效，所以 id = 1 这行数据的 name 字段还是旧值jay ，而 binlog 里面记录了这条更 新语句，在主从 架构 中，binlog 会被复制到 从库，从库执行了
这条更 新语句，那么这一行 name 字段是新值 xiaolin ，与主 库的值不一致性；
可以看到，在持久化 redo log 和 binlog 这两份日志的时候，如果出现半成功的状态，就会造成主从环境的数据不一致性。这是因为 redo log 影响主库的数据，binlog 影响从库的数据，所以 redo log 和 binlog 必须保持一致才能保证主从 数据一致。
MySQL 为了 避免出现两份日志之间的逻辑不一致的问题，使用了「两阶段提交」来解决，两阶段
提交其实是分布式事务一致性协议，它可以保 证多个逻辑操作要不全部成功，要不全部失败，不
会出现半成功的状态。
两阶段提交把单个事 务的提交拆分成了 2 个阶段，分别 是「准备（Prepare ）阶段」和「提交
（Commit ）阶段」，每个阶段都由协调者（Coordinator ）和参与者（Participant ）共同完成。注
意，不要把提交（Commit ）阶段和 commit 语句混淆了，commit 语句执行的时候，会包含提交
（Commit ）阶段。
举个 拳击比赛的例子，两位拳击手（参与者）开始比赛之前，裁判（协调者）会在中间确认两位
拳击手的状态，类似于问你准备好 了吗？
准备阶段：裁判（协调者）会依 次询问两位拳击手（参与者）是否准备好 了，然后拳击手听到
后做出应答，如果觉得自己准备好 了，就会跟裁判说准备好 了；如果没有自己还没有准备好
（比如拳套还没有带好），就会跟裁判说还没准备好 。
提交阶段：如果两位拳击手（参与者）都回答准备好 了，裁判（协调者）宣布比赛正式开 始，
两位拳击手就可以直接开打；如果任何 一位拳击手（参与者）回答没有准备好 ，裁判（协调者）
会宣布比赛暂停，对应事务中的回滚操作。
两阶段提交的过程是怎样的？
在 MySQL 的 InnoDB 存储引擎中，开启 binlog 的情况下，MySQL 会同时维护 binlog 日志与
InnoDB 的 redo log ，为了 保证这两个 日志的一致性，MySQL 使用了内部 XA 事务（是的，也有外
部 XA 事务，跟本文不太相关，我就不介 绍了），内部 XA 事务由 binlog 作为协调者，存储引擎是
参与者。
当客⼾端执行 commit 语句或者在自动提交的情况下，MySQL 内部开启一个 XA 事务，分两阶段
来完成 XA 事务的提交，如下图：
从图中可看出，事务的提交过程有两个 阶段，就是将 redo log 的写入拆成 了两个 步骤：prepare
和 commit ，中间再穿插写入binlog ，具体如下：
prepare 阶段：将 XID （内部 XA 事务的 ID ） 写入到 redo log ，同时将 redo log 对应的事务状
态设置为 prepare ，然后将 redo log 持久化到磁盘（innodb_flush_log_at_trx_commit = 1 的作用）；
commit 阶段：把 XID 写入到 binlog ，然后将 binlog 持久化到磁盘（sync_binlog = 1 的作用），接着调用引擎的提交事 务接口，将 redo log 状态设置为 commit ，此时该状态并不需要持
久化到磁盘，只需要 write 到文件系统的 page cache 中就够了，因为只要 binlog 写磁盘成功，
就算 redo log 的状态还是 prepare 也没有关系，一样会被认为事 务已经执行成功；
异常重启会出现什么 现象？
我们来看看 在两阶段提交的不同时刻，MySQL 异常重启会出现什么 现象？下图中有时刻 A 和时刻
B 都有可能发生崩溃：
不管是时 刻 A（redo log 已经写入磁盘， binlog 还没写入磁盘），还是时 刻 B （redo log 和
binlog 都已经写入磁盘，还没写入 commit 标识）崩溃，此时的 redo log 都处于 prepare 状态。
在 MySQL 重启后 会按顺序扫描 redo log 文件，碰到处于 prepare 状态的 redo log ，就拿着 redo log 中的 XID 去 binlog 查看是否存在此 XID ：
如果 binlog 中没有当前内部 XA 事务的 XID ，说明 redolog 完成刷盘，但是 binlog 还没有刷
盘，则回滚事务。对应时刻 A 崩溃恢复的情况。
如果 binlog 中有当前内部 XA 事务的 XID ，说明 redolog 和 binlog 都已经完成了刷盘，则提
交事 务。对应时刻 B 崩溃恢复的情况。
可以看到，对于处于 prepare 阶段的 redo log ，即可以提交事 务，也可以回滚事务，这取决于是
否能在 binlog 中查找到与 redo log 相同的 XID ，如果有 就提交事 务，如果没有就回滚事务。这样
就可以保 证 redo log 和 binlog 这两份日志的一致性了。
所以说，两阶段提交是以 binlog 写成功为事 务提交成功的标识，因为 binlog 写成功了，就意味着
能在 binlog 中查找到与 redo log 相同的 XID 。
处于 prepare 阶段的 redo log 加上完整 binlog ，重启就提交事 务，MySQL 为什么 要这么设计?
binlog 已经写入了，之后就会被从库（或者用这个 binlog 恢复出来的库）使用。
所以，在主库上也 要提交这个事 务。采用这个策略，主库和备库的数据就保证了一致性。
事务没提交的时候，redo log 会被持久化到磁盘吗？
会的。
事务执行中间过程的 redo log 也是直接写在 redo log buffer 中的，这些缓存在 redo log buffer 里
的 redo log 也会被「后台 线程」每隔一秒一起持久化到磁盘。
也就是说，事务没提交的时候，redo log 也是可能被持久化到磁盘的 。
有的同学可能会问，如果 mysql 崩溃了，还没提交事 务的 redo log 已经被持久化磁盘了，mysql
重启后 ，数据不就不一致了？
放心，这种情况 mysql 重启会进行回滚操作，因为事 务没提交的时候，binlog 是还没持久化到磁
盘的 。
所以， redo log 可以在事务没提交之 前持久化到磁盘，但是 binlog 必须在事务提交之 后，才可以
持久化到磁盘。
两阶段提交有什么 问题？
两阶段提交虽然保证了两个 日志文件的数据一致性，但是性能很差，主要有两个 方面的影响：
磁盘 I/O 次数高：对于“双1” 配置，每个事 务提交都会进行两次 fsync （刷盘），一次是 redo log
刷盘，另一次是 binlog 刷盘。
锁竞争激烈：两阶段提交虽然能够保证「单事务」两个 日志的内容一致，但在「多事务」的情
况下，却不能保证两者的提交顺序一致，因此，在两阶段提交的流程基础上，还需要加一个锁
来保证提交的原子性，从而保证多事务的情况下，两个 日志的提交顺序一致。
为什么两 阶段提交的磁盘 I/O 次数会很高？
binlog 和 redo log 在内存中都对应的缓存空间，binlog 会缓存在 binlog cache ，redo log 会缓存
在 redo log buffer ，它们持久化到磁盘的 时机分别 由下面这两个 参数控制。一般我们为了 避免日志
丢失的⻛险，会将这两个 参数设置为 1：
当 sync_binlog = 1 的时候，表示每次 提交事 务都会将 binlog cache 里的 binlog 直接持 久到磁盘；
当 innodb_flush_log_at_trx_commit = 1 时，表示每次 事务提交时，都将缓存在 redo log buffer里的 redo log 直接持 久化到磁盘；
可以看到，如果 sync_binlog 和 当 innodb_flush_log_at_trx_commit 都设置为 1，那么在每个事 务提交过程中， 都会至少调用 2 次刷盘操作，一次是 redo log 刷盘，一次是 binlog 落盘，所以这
会成为性能瓶颈。
为什么 锁竞争激烈？
在早期的 MySQL 版本中，通过使用 prepare_commit_mutex 锁来保证事务提交的顺序，在一个事
务获取到锁时才能进入 prepare 阶段，一直到 commit 阶段结束才能释放锁，下个事 务才可以继续
进行 prepare 操作。
通过加锁虽然完美地解决了顺序一致性的问题，但在并发量较大的时候，就会导致对锁的争用，
性能不佳。
组提交
MySQL 引入了 binlog 组提交（group commit ）机制，当有多个事 务提交的时候，会将多个
binlog 刷盘操作合并成一个，从而减少磁盘 I/O 的次数，如果说 10 个事 务依次排队刷盘的 时间成
本是 10 ，那么将这 10 个事 务一次性一起刷盘的 时间成本则近似于 1。
引入了组提交机制后，prepare 阶段不变，只针对 commit 阶段，将 commit 阶段拆分为三个 过
程：
flush 阶段：多个事 务按进入的顺序将 binlog 从 cache 写入文件（不刷盘）；
sync 阶段：对 binlog 文件做 fsync 操作（多个事 务的 binlog 合并一次刷盘）；
commit 阶段：各个事 务按顺序做 InnoDB commit 操作；
上面的每个阶段都有一个队列，每个阶段有锁进行保护，因此保证了事 务写入的顺序，第一个进
入队列的事务会成为 leader ，leader 领导所在队列的所有事务，全权负责 整队的操作，完成后通知
队内其 他事 务操作结束。
对每个阶段引入了队列后，锁就只针对每个队列进行保护，不再锁住提交事 务的整个过程，可以
看的出来，锁粒度减小了，这样就使得多个阶段可以并发执行，从而提升效率。
有 binlog 组提交，那有 redo log 组提交吗？
这个要看 MySQL 版本，MySQL 5.6 没有 redo log 组提交，MySQL 5.7 有 redo log 组提交。
在 MySQL 5.6 的组提交逻辑中，每个事 务各自执行 prepare 阶段，也就是各自将 redo log 刷盘，
这样就没办法对 redo log 进行组提交。
所以在 MySQL 5.7 版本中，做了个 改进，在 prepare 阶段不再让事务各自执行 redo log 刷盘操
作，而是推迟到组提交的 flush 阶段，也就是说 prepare 阶段融合在了 flush 阶段。
这个优化是将 redo log 的刷盘延迟到了 flush 阶段之中 ，sync 阶段之前。通过延迟写 redo log 的
方式，为 redolog 做了一次组写入，这样 binlog 和 redo log 都进行了优化。
接下来介绍每个阶段的过程，注意下面的过程针对的是“双 1” 配置（sync_binlog 和
innodb_flush_log_at_trx_commit 都配 置为 1）。flush 阶段
第一个事 务会成为 flush 阶段的 Leader ，此时后面到来的事务都是 Follower ：
接着，获取队列中的事务组，由绿色事务组的 Leader 对 redo log 做一次 write + fsync ，即一次将同组事务的 redolog 刷盘：
完成了 prepare 阶段后，将绿色这一组事务执行过程中产 生的 binlog 写入 binlog 文件（调用
write ，不会调用 fsync ，所以不会刷盘，binlog 缓存在操作系统的文件系统中）。
从上 面这个过程，可以知道 flush 阶段队列的作用是用于支撑 redo log 的组提交。
如果在这一步完成后数据库崩溃，由于 binlog 中没有该组事务的记录，所以 MySQL 会在重启后
回滚该组事务。
sync 阶段
绿色这一组事务的 binlog 写入到 binlog 文件后，并不会⻢上执行刷盘的 操作，而是会等待一段时
间，这个等待的时⻓由 Binlog_group_commit_sync_delay 参数控制，目的是为了 组合更多事务的binlog ，然后再一起刷盘，如下过程：
不过，在等待的过程中，如果事务的数量提前达到了 Binlog_group_commit_sync_no_delay_count参数设置的值，就不用继续等待了，就⻢上将 binlog 刷盘，如下图：
从上 面的过程，可以知道 sync 阶段队列的作用是用于支持 binlog 的组提交。
如果想提升 binlog 组提交的效果，可以通过设置下面这两个 参数来实现：
binlog_group_commit_sync_delay= N ，表示在等待 N 微妙后，直接调用 fsync ，将处于文件系统中 page cache 中的 binlog 刷盘，也就是将「 binlog 文件」持久化到磁盘。
binlog_group_commit_sync_no_delay_count = N ，表示如果队列中的事务数达到 N 个，就忽视
binlog_group_commit_sync_delay 的设置，直接调用 fsync ，将处于文件系统中 page cache 中的 binlog 刷盘。
如果在这一步完成后数据库崩溃，由于 binlog 中已经有了事 务记录，MySQL 会在重启后 通过 redo log 刷盘的 数据继续进行事务的提交。
commit 阶段
最后进入 commit 阶段，调用引擎的提交事 务接口，将 redo log 状态设置为 commit 。
commit 阶段队列的作用是承接 sync 阶段的事务，完成最后的引擎提交，使得 sync 可以尽早的处
理下一组事务，最大化组提交的效率。
MySQL 磁盘 I/O 很高，有什么 优化的方法？
现在我们知道事务在提交的时候，需要将 binlog 和 redo log 持久化到磁盘，那么如果出现
MySQL 磁盘 I/O 很高的现象，我们可以通过控制以下参数，来 “延迟” binlog 和 redo log 刷盘的
时机，从而降低磁盘 I/O 的频率：
设置组提交的两个 参数： binlog_group_commit_sync_delay 和
binlog_group_commit_sync_no_delay_count 参数，延迟 binlog 刷盘的 时机，从而减少 binlog的刷盘次数。这个方法是基于“额外的故意等待”来实现的，因此可能会增加语句的响应时间，
但即使 MySQL 进程中途挂了，也没有丢失数据的⻛险，因为 binlog 早被写入到 page cache
了，只要系统没有宕机，缓存在 page cache 里的 binlog 就会被持久化到磁盘。
将 sync_binlog 设置为大于 1 的值（比较常⻅是 100~1000 ），表示每次 提交事 务都 write ，但累
积 N 个事 务后才 fsync ，相当于延迟了 binlog 刷盘的 时机。但是这样做的⻛险是，主机掉电时
会丢 N 个事 务的 binlog 日志。
将 innodb_flush_log_at_trx_commit 设置为 2。表示每次 事务提交时，都只是缓存在 redo log buffer 里的 redo log 写到 redo log 文件，注意写入到「 redo log 文件」并不意味着写入到了
磁盘，因为操作系统的文件系统中有个 Page Cache ，专⻔用来缓存文件数据的，所以写入「
redo log 文件」意味着写入到了操作系统的文件缓存，然后交由操作系统控制持久化到磁盘的 时
机。但是这样做的⻛险是，主机掉电的时候会丢数据。
总结
具体更新一条记录 UPDATE t_user SET name = 'xiaolin' WHERE id = 1; 的流程如下:
1. 执行器负责 具体执行，会调用存储引擎的接口，通过主键索引树搜索获取 id = 1 这一行记录：
如果 id=1 这一行所在的数据⻚本来 就在 buffer pool 中，就直接返回给执行器更新；如果记录不在 buffer pool ，将数据⻚从磁盘读入到 buffer pool ，返回记录给执行器。
- 执行器得到聚簇索引记录后，会看一下更新前的记录和更新后的记录是否一样：
如果一样的话就不进行后续更新流程；
如果不一样的话就把更新前的记录和更新后的记录都当作参数传给 InnoDB 层，让 InnoDB
真正的执行更新记录的操作；
- 开启事务， InnoDB 层更新记录前，首先要记录相应的 undo log ，因为这是更新操作，需要把
被更新的列的旧值记下来，也就是要生成一条 undo log ，undo log 会写入 Buffer Pool 中的
Undo ⻚面，不过在内存修改该 Undo ⻚面后，需要记录对应的 redo log 。
- InnoDB 层开始更新记录，会先更新内存（同时标记为脏⻚），然后将记录写到 redo log 里面，
这个时候更新就算完成了。为了 减少磁盘I/O ，不会立即将脏⻚写入磁盘，后续由后台 线程选择
一个合适的时机将脏⻚写入到磁盘。这就是 WAL 技术，MySQL 的写操作并不是立刻写到磁盘
上，而是先写 redo 日志，然后在合适的时间再将修改的行数据写到磁盘上。
至此，一条记录更新完了。
在一条更 新语句执行完成后，然后开始记录该语句对应的 binlog ，此时记录的 binlog 会被保存
到 binlog cache ，并没有刷新到硬盘上的 binlog 文件，在事务提交时才会统一将该事务运行过
程中的所有 binlog 刷新到硬盘。
- 事务提交（为了 方便说明，这里不说组提交的过程，只说两阶段提交）：
prepare 阶段：将 redo log 对应的事务状态设置为 prepare ，然后将 redo log 刷新到硬盘；
commit 阶段：将 binlog 刷新到磁盘，接着调用引擎的提交事 务接口，将 redo log 状态设置
为 commit （将事务设置为 commit 状态后，刷入到磁盘 redo log 文件）；
- 至此，一条更 新语句执行完成。