讲讲 MySQL 中的 WAL 策略和 CheckPoint 技术

若有收获,请记得分享和转发哦

InnoDB 体系架构

在说 WAL 之前，有必要简单介绍下 InnoDB 存储引擎的体系架构，方便我们理解下文，并且 redo log 也是 InnoDB 存储引擎所特有的。

如下图，InnoDB 存储引擎由内存池和一些后台线程组成：

内存池

先来解释下内存池。

首先，我们需要知道，InnoDB 存储引擎是基于磁盘存储的，并将其中的记录按照页的方式进行管理。因此可将其视为基于磁盘的数据库系统（Disk-base Database），在这样的系统中，众所周知，由于 CPU 速度与磁盘速度之间的不匹配，通常会使用缓冲池技术来提高数据库的整体性能。

后台线程

后台线程其实最大的作用就是用来完成 “将从磁盘读到的页存放在缓冲池中” 以及 “将缓冲池中的数据以一定的频率刷新到磁盘上” 这俩个操作的，当然了，还有其他的作用。以下是《MySQL 技术内幕：InnoDB 存储引擎 - 第 2 版》对于后台线程的描述：

后台线程的主要作用就是刷新内存池中的数据，保证内存池中缓存的是最近的数据；此外将已修改的数据文件刷新到磁盘文件，同时保证在数据库发生异常的情况下 InnoDB 能恢复到正常运行状态。

另外，InnoDB 存储引擎是多线程的模型，也就是说它拥有多个不同的后台线程，负责处理不同的任务。这里简单列举下几种不同的后台线程：

redo log 与 WAL 策略

InnoDB 存储引擎会先写 redo log file 0，当 file 0 被写满的时候，会切换至 redo log file 1，当 file 1 也被写满时，会切换到 redo log file 2 中，而当 file 2 也被写满时，会再切换到 file 0 中。

可以看出，redo log file 的大小设置对于 InnoDB 存储引擎的性能有着非常大的影响：

• redo log file 不能设置得太大，如果设置得很大，在恢复时可能需要很长的时间
• redo log file 又不能设置得太小了，否则可能导致一个事务的日志需要多次切换重做日志文件

CheckPoint 技术

所谓 redo log 不可用就是所有的 redo log file 都写满了。但事实上，其实 redo log 中的数据并不是时时刻刻都是有用的，那些已经不再需要的部分就称为 ”可以被重用的部分“，即当数据库发生宕机时，数据库恢复操作不需要这部分的 redo log，因此这部分就可以被覆盖重用（或者说被擦除）。

举个例子来具体解释下：一组 4 个文件，每个文件的大小是 1GB，那么总共就有 4GB 的 redo log file 空间。write pos 是当前 redo log 记录的位置，随着不断地写入磁盘，write pos 也不断地往后移，就像我们上文说的，写到 file 3 末尾后就回到 file 0 开头。CheckPoint 是当前要擦除的位置（将 Checkpoint 之前的页刷新回磁盘），也是往后推移并且循环的：

有了 bin log 为什么还需要 redo log？

前文我们讲过，MySQL 架构可以分成俩层，一层是 Server 层，它主要做的是 MySQL 功能层面的事情；另一层就是存储引擎，负责存储与提取相关的具体事宜。

redo log 是 InnoDB 引擎特有的日志，而 Server 层也有自己的日志，包括错误日志（error log）、二进制日志（binlog）、慢查询日志（slow query log）、查询日志（log）。