MySQL 日志系统

目录

• 日志系统
  • 日志模块
    • redo log
    • binlog
  • 一条更新 SQL 语句执行过程
    • 两阶段提交

日志系统

上一篇学习了 SQL 的执行过程，这一篇主要的学习内容就在其基础上新增了一个重要的知识点，日志系统。

查询 SQL 语句执行回顾

mysql> select * from T where ID=10；

1. 建立连接
2. 查询缓存
3. 语义语法分析
4. 语句优化
5. 执行执行，调用存储引擎接口查询数据
6. 返回结果

日志模块

redo log

孔乙己喝酒的店铺老板

每个人喝酒吃肉不一定带够钱，所以有人会赊账，老板有一个记账本。但是老板每天很忙，来一个人就去翻一翻账，来一个人就去翻一翻账，很繁琐，而且记得多了，翻一次要翻好久，所以每个人的账务会先记在一块板子上，等不忙的时候再去记到记账本，然后把板子上的账务擦掉。

MySQL 的更新操作与其类似，有更新操作会先记录到一个叫做 redo log 的板子上，等没人的时候在记录到存储文件中。这就是 MySQL 日志系统中的一个重要角色 redo log

redo log 是一个可循环写的一个文件组。如一组 4 个文件 0 - 1 - 2 - 3 。

redo log 中有两个记录点

1. write pos 用来记录当前写到哪了。
2. checkpoint 检查点，开始的地方，因为可循环写，所以这个点也就是要被擦除的点。

write pos 是当前记录的位置，一边写一边后移，写到第 3 号文件末尾后就回到 0 号文件开头。checkpoint 是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。

write pos 和 checkpoint 之间的是“粉板”上还空着的部分，可以用来记录新的操作。如果 write pos 追上 checkpoint，表示“粉板”满了，这时候不能再执行新的更新，得停下来先擦掉一些记录，把 checkpoint 推进一下。

有个 redo log 之后，InnoDB 引擎在数据库服务宕机的时候，仍然可以将数据恢复，前提是事务已经提交。这个能力成为 crash-safe

crash-safe ： 赊账记录记在了粉板上或写在了账本上，之后即使掌柜忘记了，比如突然停业几天，恢复生意后依然可以通过账本和粉板上的数据明确赊账账目。

MySQL 整体来看有两块：一块是 Server 层，它主要做的是 MySQL 功能层面的事情；还有一块是引擎层，负责存储相关的具体事宜。上面我们聊到的粉板 redo log 是 InnoDB 引擎特有的日志，而 Server 层也有自己的日志，称为 binlog（归档日志）。

binlog

最开始的时候存储引擎只有 MySQL 自己的 MyISAM，但是 MyISAM 没有 crash-safe 的功能。bin log 只能用于归档。InnoDB 是另外一家公司的存储引擎，为了解决 crash-safe 的问题，开发了 redo log 这个功能。

这两种日志有以下三点不同。

1. redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。
2. redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ”。
3. redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

一条更新 SQL 语句执行过程

通过一条更新 SQL 来了解学习 MySQL 的日志系统。

mysql> create table T(ID int primary key, c int);

将 ID=2 这一行的值加 1

mysql> update T set c=c+1 where ID=2;

更新语句的执行过程

1. 连接
2. 语义语法分析
3. 语句优化
4. 执行器执行 a. 通过存储引擎找到 id 为 2 的记录。 b. 将结果 +1 在调用存储引擎进行数据存储。 c. 引擎更新结果到内存，记录 redo log ，此时 redo log 处于 prepare 状态，反馈给执行器自己随时可以提交事务。 d. 执行器生成 binlog ，记录到磁盘。 e. 调用存储引擎事务提交接口，redo log 状态由 prepare 改为 commit；

两阶段提交

redo log 的两阶段提交，由它来保证 crash-safe 。

第一阶段 prepare，然后进行逻辑日志记录 binlog ，记录完成之逅，调用存储引擎的事务提交方法，此时 redo log 到第二阶段 commit；

redo log 为了解决即时性问题。 因为文件可循环写binlog 为了解决长时间历史性问题。

因为文件追加写使用两阶段提交保证了即时和历史数据的一致性。

通过 redo log 可以恢复近期数据，比如断点，异常重启等短期数据。

通过 binlog 可以恢复到某个时间点的数据。

上述具体时间可配。