MySQL中存在三种日志：
- undo log（回滚日志） ：是 Innodb 存储引擎层生成的日志，实现了事务中的原子性 ，主要用于事务回滚和 MVCC。
- redo log（重做日志） ：是 Innodb 存储引擎层生成的日志，实现了事务中的持久性 ，主要用于掉电等故障恢复；
- binlog （归档日志） ：是 Server 层生成的日志，主要用于数据备份和主从复制；
一、回滚日志undo log
undo log（回滚日志），它保证了事务的ACID中的原子性（Atomicity） 。undo log 是一种用于撤销回退的日志。在事务没提交之前，MySQL 会先记录更新前的数据到 undo log 日志文件里面，当事务回滚时，就读取 undo log 里的数据，然后做原先相反操作。
一条记录的每一次更新操作产生的 undo log 格式都有一个roll_pointer 指针 和一个 trx_id 事务id：
- 通过 trx_id 可以知道该记录是被哪个事务修改的；
- 通过 roll_pointer 指针可以将这些 undo log 串成一个链表，这个链表就被称为版本链；
另外，可以通过 ReadView + undo log 实现 MVCC（多版本并发控制）。对于「读提交」和「可重复读」隔离级别的事务来说，它们的快照读（普通 select 语句）是通过 Read View + undo log 来实现的，它们的区别在于创建 Read View 的时机不同：
- 读提交 隔离级别是在每个 select 都会生成一个新的 Read View，也意味着，事务期间的多次读取同一条数据，前后两次读的数据可能会出现不一致，因为可能这期间另外一个事务修改了该记录，并提交了事务。
- 可重复读 隔离级别是启动事务时生成一个 Read View，然后整个事务期间都在用这个 Read View，这样就保证了在事务期间读到的数据都是事务启动前的记录。
undo log 两大作用：
- 实现事务回滚，保障事务的原子性。事务处理过程中，如果出现了错误或者用户执 行了 ROLLBACK 语句，MySQL 可以利用 undo log 中的历史数据将数据恢复到事务开始之前的状态。
- 实现 MVCC（多版本并发控制）关键因素之一 。MVCC 是通过 ReadView + undo log 实现的。undo log 为每条记录保存多份历史数据，MySQL 在执行快照读（普通 select 语句）的时候，会根据事务的 Read View 里的信息（trx_id 和 roll_pointer），顺着 undo log 的版本链找到满足其可见性的记录，从而控制并发事务访问同一个记录时的行为。
undo log 是如何刷盘（持久化到磁盘）的？
undo log 和数据页的刷盘策略是一样的，都需要通过 redo log 保证持久化。
buffer pool 中有 undo 页，对 undo 页的修改也都会记录到 redo log。redo log 会每秒刷盘，提交事务时也会刷盘，数据页和 undo 页都是靠这个机制保证持久化的。
Buffer Pool
MySQL 的数据都是存在磁盘中的，要更新一条记录的时候，得先要从磁盘读取该记录，然后在内存中修改这条记录。将修改完的记录缓存起来，下次查询语句命中这条记录时，直接读取缓存中的记录，不需要从磁盘获取数据了。Innodb 存储引擎设计了一个缓冲池（Buffer Pool），来提高数据库的读写性能。
InnoDB 会把存储的数据划分为若干个「页」，以页作为磁盘和内存交互的基本单位，一个页的默认大小为 16KB。因此，Buffer Pool 同样需要按「页」来划分。
在 MySQL 启动的时候，InnoDB 会为 Buffer Pool 申请一片连续的内存空间，然后按照默认的16KB的大小划分出一个个的页， Buffer Pool 中的页就叫做缓存页。此时这些缓存页都是空闲的，之后随着程序的运行，才会有磁盘上的页被缓存到 Buffer Pool 中。
Buffer Pool 除了缓存「索引页」和「数据页」，还包括了 Undo 页，插入缓存、自适应哈希索引、锁信息等等。
InnoDB 引擎会在适当的时候，由后台线程将缓存在 Buffer Pool 的脏页刷新到磁盘里，这就是 WAL （Write-Ahead Logging）技术 。WAL 技术指的是， MySQL 的写操作并不是立刻写到磁盘上，而是先写日志，然后在合适的时间再写到磁盘上。
二、重做日志redo log
redo log 保证了事务四大特性中的持久性。redo log 是物理日志，记录了某个数据页做了什么修改，例如对 XXX 表空间中的 YYY 数据页 ZZZ 偏移量处做了AAA 更新，每当执行⼀个事务就会产生⼀条或多条物理日志。在事务提交时，只要先将 redo log 持久化到磁盘即可。
redo log和undo log的区别是什么？
undo log 和 redo log 这两个日志都是 Innodb 存储引擎生成的。
- redo log 记录了此次事务「完成后」的数据状态，记录的是更新之后的值；
- undo log 记录了此次事务「开始前」的数据状态，记录的是更新之前的值；
事务提交之前发生崩溃，重启后会通过 undo log 回滚事务，事务提交之后发生崩溃，重启后会通过 redo log 恢复事务。
redo log 作用：
- 实现事务的持久性，让 MySQL 有 crash-safe 的能力，能够保证 MySQL 在任何时间段突然崩溃，重启后之前已提交的记录都不会丢失；
- 将写操作从「随机写」变成了「顺序写」，提升 MySQL 写入磁盘的性能。
三、归档日志 binlog
binlog 文件是记录了所有数据库表结构变更和表数据修改的日志，不会记录查询类的操作。
MySQL 在完成一条更新操作后，Server 层还会生成一条 binlog，等之后事务提交的时候，会将该事物执行过程中产生的所有 binlog 统一写 入 binlog 文件。
redo log和bin log有什么区别？
1. 适用对象不同：
binlog 是 MySQL 的 Server 层实现的，所有存储引擎都可以使用；
redo log 是 Innodb 存储 引擎实现的日志。
2. 文件格式不同：
redo log 是物理日志，记录的是在某个数据页做了什么修改；
binlog 主要包括三种格式： Statement 、 Row 和 Mixed 。
3. 写入方式不同：
binlog 是追加写，写满⼀个⽂件，就创建⼀个新的文件继续写，不会覆盖以前的⽇志，保存 的是全量的日志。
redo log是循环写，日志空间大小是固定，全部写满就从头开始，保存未被刷⼊磁盘的脏页日志。
4. 用途不同：
binlog 用于备份恢复、主从复制；
redo log 用于掉电等故障恢复。
binlog 什么时候刷盘？
事务执行过程中，先把日志写到 binlog cache（Server 层的 cache），事务提交的时候，再把 binlog cache 写到 binlog 文件中。
一个事务的 binlog 是不能被拆开的，因此无论这个事务有多大也要保证一次性写入。这是因为有一个线程只能同时有一个事务在执行的设定，所以每当执行一个 begin/start transaction 的时候，就会默认提交上一个事务，这样如果一个事务的 binlog 被拆开的时候，在备库执行就会被当做多个事务分段执行，这样破坏了原子性，是有问题的。
MySQL 给每个线程分配了一片内存用于缓冲 binlog ，该内存叫 binlog cache，参数 binlog_cache_size 用于控制单个线程内 binlog cache 所占内存的大小。如果超过了这个参数规定的大小，就要暂存到磁盘。
四、两阶段提交
事务提交后，redo log 和 binlog 都要持久化到磁盘，但是这两个是独立的逻辑，可能出现半成功的状态，这样就造成两份日志之间的逻辑不一致。
- 如果在将 redo log 刷入到磁盘之后， MySQL 突然宕机了，而 binlog 还没有来得及写入。MySQL 重启后，通过 redo log 能将 Buffer Pool 恢复到新值，但是 binlog 里面没有记录这条更新语句，在主从架构中，binlog 会被复制到从库，由于 binlog 丢失了这条更新语句，从库的这一行 name 字段是旧值，与主库的值不一致性；
- 如果在将 binlog 刷入到磁盘之后， MySQL 突然宕机了，而 redo log 还没有来得及写入。由于 redo log 还没写，崩溃恢复以后这个事务无效，所以数据字段还是旧值，而 binlog 里面记录了这条更新语句，在主从架构中，binlog 会被复制到从库，从库执行了这条更新语句，那么这一行新值，与主库的值不一致性；
redo log 影响主库的数据，binlog 影响从库的数据，所以 redo log 和 binlog 必须保持一致才能保证主从数据一致。
两阶段提交把单个事务的提交拆分成了 2 个阶段，分别是「准备（Prepare）阶段」和「提交（Commit）阶段」，每个阶段都由协调者（Coordinator）和参与者（Participant）共同完成。
两阶段提交过程
MySQL 会同时维护 binlog 日志与 InnoDB 的 redo log，为了保证这两个日志的一致性，MySQL 使用了内部 XA 事务，内部 XA 事务由 binlog 作为协调者，存储引擎是参与者。
事务的提交过程有两个阶段，将 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 也没有关系，一样会被认为事务已经执行成功。