目录

• 背景
• 物理日志和逻辑日志
• 日志模块：redo log
  • redo log产生背景
  • redo log基本概念
  • redo log记录形式
  • redo log使用场景
• 日志模块：bin log
  • bin log基本概念
  • bin log刷盘机制
  • bin log使用场景
• 日志模块：undo log
  • undo log基本概念
  • undo log使用场景
• binlog/redo log/undo log区别
• 闲聊
• 【迈莫coding】

背景

日志是mysql数据库的重要组成部分，记录着数据库运行期间各种状态信息。mysql日志主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类。作为开发，我们重点需要关注的是二进制日志(bin log)和事务日志(包括redo log和undo log)，本文接下来会详细介绍这三种日志。

物理日志和逻辑日志

在说日志模块前，先剧透一下什么是物理日志和逻辑日志，以防有小伙伴不太熟悉这两个词，所以先学习一下，这样看日志模块时见到这两个词不至于生疏。

• 物理日志：通俗的讲，就是只有"我"自己可以使用，别人无法共享我的"物理格式，私有化。
• 逻辑日志：可以给别的引擎使用，是所有引擎共享的。

日志模块:redolog

redo log产生背景

说mysql日志redo log，先说一个故事。从前有一家酒馆，酒馆老板常备着一个粉板，专门记着客人的赊账记录，也是他的法宝之一。如果赊账的人不多，他可以在粉板上记录下赊账的人和账目。如果赊账人多的话，由于粉板的空间大小有限，所以他又需要额外准备一本账本，专门记录所有赊账的账目。

如果有人要赊账的话，一般老板有两种做法：

• 打开账本，找到赊账人的记录，进行追加赊账记录
• 先把赊账人的记录写到粉板上，待客流量少的时刻，再更新到赊账账目上

如果老板使用第一种方法的话，每当有人要赊账的话，首先他需要打开厚厚的账本，一页一页查找该顾客的姓名，然后进行登记。你们想啊，如果赊账的人不多，老板找赊账人的记录轻松点，如果赊账本有好几本的话，一本一本的找，老板看的都头疼。

方案一的过程想想都头大。相比第二种方案，对老板就相对轻松点，老板只需要把赊账人的信息写在粉板上，待客流量低的时候，再更新到赊账本上。

同样，mysql里也有同样的问题，如果每一次数据的操作都写入磁盘中，首先磁盘先要找到对应的记录，然后再更新，整个过程io成本，查找成本比较高。所以，mysql为了提高性能，使用了类似老板粉板方式，先把更新数据结果存储到某个地方，待空闲时再写入磁盘中。

而mysql把更新结果存储的地方，就是咱们今天所说的主角之一redo log。接下里，咱们就好好和主角交流交流。

redo log基本概念

redo log是InnoDB存储引擎层的日志，又被称为重写日志，用来记录事务操作的变化，记录的是数据修改之后的值，不管事务提交是否成功，都会被记录下来。

而这种先写日志，后写磁盘的技术就是mysql里面经常提及到的WAL(Write Ahead Logging)技术。

具体的来说，就是当有一条记录需要更新的时候，InnoDB引擎会把记录优先更新到redo log（粉板）里面，并更新内存，这样更新操作就完成了。同时，InnoDB引擎会在空闲的时间将redo log中的记录存储到磁盘上。

redo log 记录方式

由于redo log记录的是数据页的变更，而这种记录是没有必要永久保存的，因此redo log实现上采用来大小固定，循环写入的方式，当记录写到末尾时，又会从头开始写，如下图所示。

在这里插入图片描述

如果和上面老板粉板场景结合起来描述的话，write pos就是老板在粉板上顺序写入赊账人记录位置，对于mysql来说，write pos后移；而check point就是老板把粉板上记录写入到赊账本上的位置，当老板写入到赊账本上后，就会把粉板上该记录擦除掉，对于mysql来说，check point后移。

redo log使用场景

• 用于系统奔溃恢复(crash-safe)

日志模块:binlog

bin log基本概念

bin log是mysql数据库service层的，是所有存储引擎共享的日志模块，它用于记录数据库执行的写入性操作，也就是在事务commit阶段进行记录，以二进制的形式保存于磁盘中。

bin log是逻辑日志，并且由mysql数据库的service层执行，也就是说使用所有的存储引擎数据库都会记录bin log日志。

bin log是以追加的方式进行写入的，可以通过 max_binlog_size 参数设置bin log文件大小，当文件大小达到某个值时，会生成新的文件来保存日志。

bin log刷盘机制

对于InnoDB引擎而言，在每次事务commit提交时才会记录bin log日志，此时记录仍然在内存中，那么什么时候存储到磁盘中呢？mysql通过 sync_binlog 参数控制bin log刷盘时机，取值范围：0～N：
0：不去强求，由系统自行判断何时写入磁盘；
1：每次事务commit的时候都要将bin log写入磁盘；
N：每N个事务commit，才会将bin log写入磁盘；

sync_binlog 参数建议设置为1，这样每次事务commit时就会把bin log写入磁盘中，这样也可以保证mysql异常重启之后bin log日志不会丢失。

bin log使用场景

在实际场景中， bin log 的主要场景有两点，一点是主从复制，另一点是数据恢复
主从复制：在master端开启 bin log ，然后将 bin log 发送给各个slaver端，slaver端读取 bin log 日志，从而使得主从数据库中数据一致
数据恢复：通过 bin log 获取想要恢复的时间段数据

日志模块:undolog

undo log基本概念

undo log 是回滚日志，是记录每条数据的所有版本，比如 update 语句，那么它首先会将该条记录的数据记录到undo log日志中，并且将最新版本的roll_pointer指针指向上一个版本，这样就可以形成当前记录的所有版本，这也是MVCC的实现机制。

MVCC实现机制，查看我的另一篇文章<<校招mysql那些事|MVCC原理机制>>。
校招mysql那些事|MVCC原理机制

undo log使用场景

• MVCC多版本控制中使用undo log

binlog/redo log/undo log区别

| | bin log | redo log | undo log |
|--|--| --| -- | -- |
| | |
|存储位置 |server层，所有引擎共享| InnoDB引擎独有 |
|文件大小| binlog可通过max_binlog_ize设置每个binlog文件大小| redo log大小是固定的
|日志名称 |归档日志 |重写日志 |回滚日志
|记录方式 |通过追加方式进行记录| 通过循环写方式进行记录，写到末尾又从开头接着写
|适用场景 |主从复制和数据恢复| 奔溃恢复 |MVCC多版本并发

闲聊

• 读完文章，自己是不是和mysql日志模块的cp率又提高了
• 我是迈莫，欢迎大家和我交流

文章也会持续更新，可以微信搜索「 迈莫coding 」第一时间阅读。