事务一：重做日志

*MySQL的事务通过redo log和undo log来实现。*

## redo log
#### 基本概念
redo log称为重做日志，用来实现数据库的持久性。通常是物理日志，记录的是页的物理修改操作。在数据恢复时，物理日志的恢复速度比逻辑日志(比如binlog)要快很多。
redo log格式如下：

| redo_log_type | space | page_no | redo log body |
| --- | --- | --- | --- |

- redo_log_type: 重做日志类型
- space：表空间ID
- page_no：页的偏移量

举例说明：
```shell
CREATE TABLE t (a INT, b INT, PARIMARY KEY(a), KEY(b))

# 执行以下SQL语句：
INSERT INTO t SELECT 1, 2;

# 会对聚集索引页和辅助索引页进行操作，记录的重做日志大致为：
page(2,3), offset 32, value 1,2
page(2,4), offset 64, value 2
```

redo log由两部分组成：
 * 一是内存中的重做日志缓冲(redo log buffer)
 * 二是重做日志文件(redo log file)

redo log 记录的是数据修改之后的值，不管事务是否提交都会记录，在事务进行的过程中会持续记录，当事务提交(commit)时，会先将redo log写入到重做日志文件中进行持久化。
> InnoDB引擎记录了对数据文件的物理更改，并保证总是日志先行，也就是所谓的WAL，即在持久化数据文件前，先保证redo log已经写入到磁盘。由于redo log是顺序整块写入，因此写入性能更好。

> 为了确保重做日志写入文件，每次将重做日志缓冲写入重做日志文件后(其实只是写入了系统缓存)，InnoDB引擎都需要调用一次fsync操作，将系统缓存中的数据写入磁盘。

## checkpoint
#### 技术背景

> 数据库在发生增删查改操作的时候，都是先在buffer pool中完成的，为了提高事务操作的效率，buffer pool中修改的数据，并没有立即写入磁盘，这有可能会导致内存中数据与磁盘中的数据产生不一致的情况，如果此时发生故障，可能会导致内存中的数据未被持久化。

> 为了防止内存中被修改但尚未写入到磁盘的数据在发生故障后数据丢失的情况，InnoDB在事务提交前都会先写重做日志文件，并保证日志先行。在发生故障重启后，未被持久化的数据可以通过redo log进行恢复，从而保证了事务的持久性。

> 但是redo log不可能无限增长，因此需要通过一定的机制将内存中的数据持久化到磁盘，那么在使用重做日志进行故障恢复时，则只需要恢复少量的数据。

**checkpoint 的工作，就是在一定条件下将脏页刷新到磁盘，并通过LSN记录位置。**

由于checkpoint 表示已经刷新到磁盘上的LSN，因此在数据恢复时，仅需要恢复checkpoint之后的日志。比如checkpoint的LSN为10000时发生宕机，恢复操作仅需要恢复10000以后的重做日志。

#### checkpoint 分类
- sharp checkpoint: 在关闭数据库的时候，将脏页刷新到磁盘
- fuzzy checkpoint: 在不同的时机，将部分脏页刷新到磁盘。

## LSN
#### 基本概念
LSN(Log Sequence Number)，日志序列号，是一个一直递增的整型数字，占8个字节。数据页、重做日志、checkpoint都有LSN
 * 数据页中的LSN，表示该页的版本
 * 重做日志中的LSN，表示重做日志写入的总量
   > 例如当前重做日志的LSN为1000，有一个事务写入了100字节的重做日志，那么LSN就变成了1100；若又有事务写入了200字节的重做日志，那么LSN就变成了1300
 * checkpoint中的LSN，表示