几年了，作为一个码农终于把MySQL日记看懂了！

三、必要概念字典介绍

基础不牢地动山摇，还是常规套路，先把必要知识普及/温习一遍，当后续文章出现疑虑反过来看下这些概念字典，说不定能 “柳暗花明又一村” 呢？

写了又写，想了又想，纠结了好久，这部分知识确实有点多，最后还是决定将这些必要概念字典单独分出一个文章，后续打算用截图方式引入各个章节中，建议遇到不懂名词查阅一下字典。

四、认识二进制日记（Binlog）

4.1 Binlog概念

Binlog 是逻辑日记，用于记录数据库执行的写入操作（查询不记录）信息，Server层记录和引擎层无关，并且是以追加方式进行写入，可以通过参数 max_binlog_size 设置每个Binlog文件的大小，文件大小达到设定值时会生成新的文件来保存日记。

4.2 Binlog 作用

在实际应用中，主要用在两个场景：主从复制和数据恢复

• 主从复制场景：在Master主端开启Binlog，将Binlog发生到各个Slave从端，Slave从端重放Binlog从而达到主从数据一致

• 数据恢复场景：通过使用 mysqlbinlog 工具来恢复数据

4.3 Binlog 记录过程及刷盘时机

Binlog何时记录将在第六点进行介绍，大致记录过程是先写Binlog Buffer，然后通过刷盘时机，控制刷入OS Buffer，控制fsync()进行写入Binlog File日记磁盘的过程。

对于Binlog，MySQL是通过参数sync_binlog参数来控制刷盘时机，取值是0、1和N三种值。0表示由系统自行判断何时调用sync()写入磁盘；1表示每次事务commit都要调用fsync()写入磁盘；N表示每N个事务，才会调用fsync()写入磁盘。

4.4 Binlog 记录格式

MySQL5.7.7版本之前默认格式是STATEMENT，版本之后默认是ROW，可以通过参数 binlog-format指定。

五、认识事务日记（Undo log）

5.1 Undo log 概念

Undo log是逻辑日记、回滚日记。比如一条修改+3的逻辑语句，Undo log会记录对应一条-3的逻辑日记，一条插入语句则会记录一条删除语句，这样发生错误时，根据执行Undo log就可以回滚到事务之前的数据状态。

5.2 Undo log 作用

• 回滚数据：当程序发生异常错误时等，根据执行Undo log就可以回滚到事务之前的数据状态，保证原子性，要么成功要么失败。

• MVCC一致性视图：通过Undo log找到对应的数据版本号，是保证MVCC视图的一致性的必要条件。

5.3 Undo log 记录过程及刷盘时机

刷盘过程及时机类似于Binlog和Redo，可以参考Redo log刷盘时机章节给出的图片，已经体现出来了。

5.4 Undo log 总结

Undo log日记内容不是很多，重点是回滚和多版本控制MVCC那块。此外，我记得印象笔记深刻的是长事务会导致日记过多，这个日记就是Undo log。因为长事务存在，导致需要保存很多视图快照，其实这里就是涉及到Undo log何时删除和生成的问题，当时纠结好久，其实很简单。生成是事务开始后写Redo log之前生成，当没有事务需要用到Undo log时就会被删除。举个例子，如果事务A一直存活，那么事务A之后产生的事务B、C…等等就算提交了，也不会被删除，因为事务A需要用到B、C…事务去找A的版本。所以避免长事务可以减少Undo log日记量，当然还可以提高性能。

六、认识事务日记 （Redo log）

6.1 Redo log 概念

Redo log 是重做日记，属于InnoDB引擎的日记。是物理日记，日记记录的内容的是数据页的更改，这个页 “做了什么改动”。如：add xx记录 to Page1，向数据页Page1增加一个记录。

6.2 Redo log 作用

• 前滚操作：具备crash-safe能力，提供断电重启时解决事务丢失数据问题。

• 提高性能：先写Redo log记录更新。当等到有空闲线程、内存不足、Redo log满了时 “刷脏”。写Redo log是顺序写入，刷脏是随机写，节省的是随机写磁盘的 IO 消耗（转成顺序写），所以性能得到提升。此技术称为WAL技术：Write-Ahead Logging，它的关键点就是先写日记磁盘，再写数据磁盘。

6.3 Redo log 的两阶段提交

更新内存后引擎层写Redo log将状态改成prepare为预提交第一阶段，Server层写Binlog，将状态改成commit为提交第二阶段。两阶段提交可以确保Binlog和Redo log数据一致性。

6.4 Redo log 容灾恢复过程

MySQL的处理过程如下

• 判断redo log是否完整，如果判断是完整（commit）的，直接用Redo log恢复

• 如果redo log只是预提交prepare但不是commit状态，这个时候就会去判断binlog是否完整，如果完整就提交Redo log，用Redo log恢复，不完整就回滚事务，丢弃数据。

只有在redo log状态为prepare时，才会去检查binlog是否存在，否则只校验redo log是否是 commit就可以啦。 怎么检查binlog：一个完整事物binlog结尾有固定的格式。

6.5 Redo log 刷盘时机

Undo log的刷盘时机和Redo log差不多，但是对于Undo log我没找到对应的刷盘参数设计，所以不再提。Redo log每次先写入Redo Log Buffer中，然后通过刷盘时机控制刷入OS Buffer时间和刷入日记磁盘的时间。

在Undo Log中，MySQL是通过参数innodb_flush_log_at_trx_commit来控制刷盘时机，取值是0、1和2三种值。0表示事务提交后，每秒写入OS Buffer并调用fsync()写入日记磁盘中；1表示每次事务提交会写入OS Buffer并调用fsync()将日记写入日记磁盘中。2表示事务每次提交写入到OS Buffer，每秒调用fsync()写入日记磁盘。可见参数为1是最安全的，同时也是默认值。

6.6 Redo log 存储方式

上图是日记磁盘的Redo log环形设计图（从头写，写到结束又从头开始写~循环）。write pos和check point是两个指针，write pos指针指向当前日记文件写入的位置，check point指针指向当前要擦除的开始位置。图中绿色部分是可以写入Redo log地方，每次写入，write pos指针会顺时针推进，当然基本不会与check point指针重合，因为MySQL有这种机制去实现，每次触发检查点checkpoint，check point会指针向前推进，这个过程就是需要进行刷日记和数据磁盘，记录相应的LSN，引出难点LSN。

6.7 Redo Log 检查点

啥时候会触发检查点checkpoint，网上找了点资料：啥时候数据库会触发检查点checkpoint

Checkpoint发生的时间、条件及脏页的选择等都非常复杂。而Checkpoint所做的事情无外乎是将缓冲池中的脏页刷回到磁盘，不同之处在于每次刷新多少页到磁盘，每次从哪里取脏页，以及什么时间触发Checkpoint。这些本文不会去研究。

6.8 Redo Log LSN

LSN这个概念，比较复杂，我介绍完你们不一定懂！LSN称为日志的逻辑序列号(log sequence number)，在innodb存储引擎中，lsn占用8个字节。LSN的值会随着日志的写入而逐渐增大。可以简单理解SLN就是记录从开始到现在已经产生了多少字节的Redo log值。

存储方式两个指针又是通过LSN计算得到指向位置，因为LSN记录的是文件的大小字节，当超过文件大小时，需要用取模计算出这两个指针位置，取模使得写入就会从头开始写，这样使得两个指针在一个文件中，一直落在循环位置，你追我赶的过程。这就是Redo log 环形逻辑思想设计实现。

上面提到LSN比较复杂，是因为它有很多个值，输入命令"show engine innodb status;"，可以看到四个的lsn记录

为了方便识别，我都为它们重新命名，如下。名词记不住，后面无法继续深入

1. 内存日记：redo log buffer lsn；磁盘日记：redo log file lsn；

一般关系为：redo log buffer lsn >= redo log file lsn，如果刷盘时机为1，则redo log buffer lsn = redo log file lsn。

1. 内存数据页：data buffer lsn；数据磁盘数据页：data disk lsn；

一般关系为data buffer lsn > data disk lsn，如果已经刷入数据磁盘，则data buffer lsn = data disk lsn。

1. 检查点：chckpoint lsn；

后面提到检查点刷盘，数据刷盘和日记刷盘（如果有日记刷盘：则说明我假设的日记刷盘的时机设置值不为1，为1是同步的，即始终redo log buffer lsn = redo log file lsn，不会由检查点触发刷日记磁盘）。

都说Redo log是环形记录，那么怎么记录的？下面结合LSN给出记录过程虚构图，可以对比6.6 Redo log 存储方式图 相关知识：日记磁盘 + redo log file lsn + checkpoint lsn + 双指针（write pos、check point）

1-8按时间顺序发生。1点是假设最初的状态；2、3点写日记磁盘；4点是触发了检查点checkpoint，进行刷盘，checkpoint lsn=1开始，刷盘结束并更新checkpoint lsn=512。在5点、6点已经刷过了一循环内存、二循环内存，从头开始写入log，两个指针指向回到了头部。第7点也是一个触发checkpoint的过程。9点是假设没有更新，最后达到平衡的结果，即内存中数据页和日记都完成了刷盘。

整个流程：

在某些情况下，触发checkpoint，触发数据页和日志页刷盘，此时将内存中的脏数据—“数据脏页"和"日志脏数据” 分别刷到数据磁盘和日记磁盘中，而且两者刷盘速度不一样。checkpoint会保护机制，当数据刷盘速度超过日志刷盘时，将会暂时停止数据刷盘，等待日志刷盘进度超过数据刷盘。

刷盘时，对于数据磁盘，全部都是在内存中，此时每次刷一个数据页到内存更新数据页也更新了data disk lsn为data buffer lsn（在更新内存数据页时，会更新data buffer lsn）。

对于日记磁盘，除了要记录checkpoint lsn的值为检查点 checkpoint的值（必须在结束时 直接记录一个值，速度很快），这里是针对日记刷盘时机不是1（1是同步缓存刷日记刷盘）时，并且日记还没刷到日记磁盘需要触发将缓存中日记提前刷到日记磁盘中，此时会将redo buffer log刷到redo log file中也更新了redo log file lsn为redo log buffer lsn 。

模拟检查点触发前后，整个流程变化，一个数据页和日记，数据变化及lsn从179-180的变化图（刷盘时机不为1）

6.9 Redo log 容灾恢复过程与LSN

结合6.4 Redo log 容灾恢复过程和6.8的LSN知识，再次细化6.4的Redo log恢复过程

重启innodb时，Redo log完不完整，采用6.4知识过程。用Redo log恢复，启动数据库时，InnoDB会扫描数据磁盘的数据页data disk lsn和日志磁盘中的checkpoint lsn。两者相等则从checkpoint lsn点开始恢复，恢复过程是利用 redo log到buffer pool，直到checkpoint lsn等于redo log file lsn，则恢复完成。

如果checkpoint lsn 小于 data disk lsn，说明在检查点触发后还没结束刷盘时数据库宕机了。因为checkpoint lsn最新值是在数据刷盘结束后才记录的，检查点之后有一部分数据已经刷入数据磁盘，这个时候数据磁盘已经写入部分的部分恢复将不会重做，直接跳到没有恢复的lsn值开始恢复。

七、了解 ChangeBuffer

7.1 为啥提到ChangeBuffer

为啥本文我会提到ChangeBuffer呢，其实很多时候会将ChangeBuffer和Redo log搞混，两者都是巧用内存，减少磁盘IO，为了不弄混我觉得有必要专门对这个进行一个讲解。

7.2 ChangeBuffer概念及作用

下面是我对ChangeBuffer的简单介绍

也就是说对于更新的操作，如果用到了ChangeBuffer，更新的数据所在的数据页如果不在内存中，将不用去数据磁盘将数据页读到内存，而是将这一次操作记录在ChangeBuffer中，ChangeBuffer 主要节省的则是随机读磁盘的 IO 消耗，下次读取查询等读取数据页时用上ChangeBuffer中的记录即可。其实也是一种巧用内存的思想。

7.3 ChangeBuffer与Redo log区别

Redo log 主要节省的是随机写磁盘的 IO 消耗（转成顺序写），而 ChangeBuffer 主要节省的则是随机读磁盘的 IO 消耗。

这句话怎么理解，看下面：

Redo log 与 ChangeBuffer(含磁盘持久化) 这2个机制，不同之处在于优化了整个变更流程的不同阶段。

先不考虑Redo log、ChangeBuffer机制，简化抽象一个更新(insert、update、delete)流程：

1. 从磁盘读取待变更的行所在的数据页，读入内存页中

2. 对内存页中的行，执行变更操作

3. 将变更后的数据页，写入至数据磁盘中

其中，流程中的步骤1涉及随机读磁盘IO；步骤3涉及随机写磁盘IO；刚好对应ChangeBuffer和Redo log。

对那句话的理解答案：

• ChangeBuffer机制，优化了步骤1——避免了随机读磁盘IO ，将不在内存中的数据页的操作写入ChangeBuffer中，而不是将数据页从磁盘读入内存页中

• Redo log机制， 优化了步骤3——避免了随机写磁盘IO，将随机写磁盘，优化为了顺序写磁盘(写Redo log，确保crash-safe)

7.4 有没有用到ChangeBuffer对于Redo log的区别

Redo log机制，为了保证crash-safe，一直都会用到。 有无用到ChangeBuffer机制，对于redo log这步的区别在于—— 用到了ChangeBuffer机制时，在Redo log中记录的本次变更，是记录new change buffer item相关的信息，而不是直接的记录物理页的变更(文章中第八节都有体现这一过程)。 在我们mysql innodb中， ChangeBuffer机制不是一直会被应用到，仅当待操作的数据页当前不在内存中，需要先读磁盘加载数据页时，ChangeBuffer才有用武之地。

7.5 ChangeBuffer的merge过程

除了访问这个数据也会触发 merge 外，系统有后台线程会定期 merge。在数据库正常关闭（shutdown）的过程中，也会执行 merge 操作。

merge过程做三步

1. 从磁盘读入数据页到内存（老版本的数据页）；

2. 从 change buffer 里找出这个数据页的 change buffer 记录 (可能有多个），依次应用，得到新版数据页；

3. 写 redo log。这个 redo log 包含了数据的变更和 change buffer 的变更。

八、日记大连贯U-R-B，一举攻破拿下

前面分别讲的是Binlog、Undo log和Redo log，下面将他们都串联起来，在一些流程体现全部日记。

同样，以一些最经典的更新语句例子展开说明。

8.1 制造演示数据

测试语句：插入语句+查询语句，a字段是普通索引
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

最后

很多程序员，整天沉浸在业务代码的 CRUD 中，业务中没有大量数据做并发，缺少实战经验，对并发仅仅停留在了解，做不到精通，所以总是与大厂擦肩而过。

我把私藏的这套并发体系的笔记和思维脑图分享出来，理论知识与项目实战的结合，我觉得只要你肯花时间用心学完这些，一定可以快速掌握并发编程。

不管是查缺补漏还是深度学习都能有非常不错的成效，需要的话记得帮忙点个赞支持一下

整理不易，觉得有帮助的朋友可以帮忙点赞分享支持一下小编~
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
把私藏的这套并发体系的笔记和思维脑图分享出来，理论知识与项目实战的结合，我觉得只要你肯花时间用心学完这些，一定可以快速掌握并发编程。

不管是查缺补漏还是深度学习都能有非常不错的成效，需要的话记得帮忙点个赞支持一下

整理不易，觉得有帮助的朋友可以帮忙点赞分享支持一下小编~
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！