Mysql，日志系统

Posted 2021-04-30 添砖加瓦的代码汪

前言

    这一部分主要围绕mysql中的日志系统展开。mysql日志这块一般来说，DBA或运维同学接触会比较多。笔者为开发同学，因此视角会比较偏向开发，主要围绕功能来说。

系列目录

第二章 Mysql的日志系统

第三章 mysql的事务隔离机制原理

第四章 索引索引索引！重要的事情说三遍

第五章 “锁”的利弊

第六章 mysql中的案例分析——实战找坑

那么话不多说，干就完事儿了！

---

Mysql的日志系统

mysql本身有没有什么容灾的方式呢，或者有什么可以追溯过去操作行为的方法等。这里就要提到mysql的日志系统了，通过日志系统，往往我们也能恢复到过期一段时间内某一时刻的db数据状态。

mysql中重要的两个概念就是redo log和binlog，粗略的翻译下分别就是重做日志和归档日志。为什么需要两种日志呢？因为日志和我们的系统日志一样，最终都是要落盘的。如果每次更新操作都有一次磁盘io交互的话效率的很低的。因此mysql的innoDB引擎的日志系统就设计了一种类似归档的机制，即WAL（write-ahead-logging），先写redo，等写满或者系统不忙的时候写binlog磁盘。如果没有这个机制，那么每次对数据的更新都需要找到binglog里对应的记录并操作修改，效率低下。

redo log和binlog的不同，主要有一下几点区别：

1. redo log属于innoDB，binlog属于mysql server层的实现

2. redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如“给 id=2 这一行的 c 字段加 1 ”

3. redolog 循环写入，包含checkpoint和writepos，记录当前归档的节点和写的位置；binlog是追加写的方式，一个文件写完了创建新的binlog文件继续写

为了保证redolog和binlog的属于强一致性，在提交的时候采用了两段式的提交方式。以给指定id的行的某一个属性+1的这样一条更新语句，更新方式如下：

1. 执行器先找引擎取 id=2 这一行。id 是主键，引擎直接用树搜索找到这一行。如果 id=2 这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。

2. 执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的一行数据；

3. 执行器调用引擎接口写入这行新数据；

4. 引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare 状态；

5. 引擎告知执行器执行完成了，随时可以提交事务；

6. 执行器生成这个操作的 binlog，并把 binlog 写入磁盘；

7. 执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成；

后记

这部分还是偏功能，没有细致的去讲底层。后面结合事务隔离的章节，会进一步展开，敬请期待。