MySQL原理(六)：日志

前言

上一篇介绍了 MySQL 的锁，这一篇将介绍日志相关的内容。

MySQL 中最常见的日志有三类：

• undo log（回滚日志）：是 Innodb 存储引擎层生成的日志，实现了事务中的原子性，主要用于事务回滚和 MVCC。
• redo log（重做日志）：是 Innodb 存储引擎层生成的日志，实现了事务中的持久性，主要用于故障恢复；
• binlog （归档日志）：是 Server 层生成的日志，主要用于数据备份和主从复制；

undo log

当一条写入类型的 SQL 执行时，都会记录一条 undo log 日志，生成相反的 SQL，比如执行一条 insert 语句后会生成一条对应的 delete 的 SQL 语句在 undo log 中。在事务回滚时，只需要按顺序执行 undo log 中的语句。

每条 undo log 都有一个 roll_pointer 指针和一个事务id trx_id：

• 通过 trx_id 可以知道该记录是被哪个事务修改的；
• 通过 roll_pointer 指针可以将这些 undo log 串成一个链表，这个链表就被称为版本链；

undo log 存储在 Undo 表空间中（.ibdata 格式文件），其中有一块区域名为 Rollback Segment（回滚段），每个回滚段中有 1024 个 Undo-log Segment，每个 Undo-log Segment 可存储一条数据，默认有 128 个回滚段，即支持 128*1024 条记录同时存在。

undo log 两大作用：

• 实现事务回滚，保障事务的原子性。事务处理过程中，如果出现了错误或者用户执行了 ROLLBACK 语句，MySQL 可以利用 undo log 中的历史数据将数据恢复到事务开始之前的状态。
• 实现 MVCC（多版本并发控制）关键因素之一。MVCC 是通过 ReadView + undo log 实现的。undo log 为每条记录保存多份历史数据，MySQL 在执行快照读（普通 select 语句）的时候，会根据事务的 ReadView 里的信息，顺着 undo log 的版本链找到满足其可见性的记录。

为什么 undo log 不像 redo log 和 binlog 一样，有缓存（redo log buffer、binlog cache）？

因为 undo log 需要实现事务回滚，如果先存入一个缓冲区，会由于 MySQL 崩溃而丢失。

insert undo log

对于 insert 类型的 SQL，会在 undo log 中记录下刚插入进来的数据 ID，根据 ID 完成删除。

有多个主键是为了解决联合主键的情况。

因为单纯的插入不涉及 MVCC，所以一旦事务提交，这条 insert undo log 就可以直接删除了。

update undo log

delete 语句使用的也是 update undo log。

持久化

undo log 类似于数据，其管理和落盘策略和数据页是一样的，都需要通过 redo log 保证持久化。

• undo log 的磁盘结构并不是顺序的，而是像数据一样按页管理；
• undo log 写入时，也像数据一样产生对应的 redo log；
• undo log 的页也像数据一样缓存在 Buffer Pool 中，跟数据页一起做 LRU 换入换出，以及刷脏；
• 对 undo 页的修改也都会记录到 redo log；
• undo 页的刷脏也像数据一样要等到对应的 redo log 落盘之后；

redo log

MySQL 中的数据是存储在磁盘上的，但是如果每次读写数据都通过磁盘的话，读写的效率会非常低，所以 InnoDB 在内存中设置了一个区域 Buffer Pool，可以直接通过内存来读取和修改数据，后续再将内存中的数据更新到磁盘中。但是内存中的数据是易失性的，可能随着进程、系统崩溃等情况而丢失，所以 MySQL 设计了 redo log 来解决这类问题。

当有一条记录需要更新的时候，InnoDB 引擎就会先更新内存（修改 Buffer Pool 中的数据页，同时标记为脏页），然后将本次对这个页的修改以 redo log 的形式记录下来（持久化到磁盘），这个时候更新就算完成了。后