【转】MySQL 的 undo log、redo log、binlog 的区别？

是个小胖墩儿啊

已于 2023-08-16 21:40:39 修改

阅读量105

点赞数

分类专栏： MySQL 文章标签：数据库

于 2022-03-31 13:24:29 首次发布

原文链接：https://mp.weixin.qq.com/s/t08ttQmgXRVhnRoH2OKNvQ

版权

25 篇文章 4 订阅

订阅专栏

转自：
https://mp.weixin.qq.com/s/t08ttQmgXRVhnRoH2OKNvQ

在这里插入图片描述

事务开始之前，将当前事务版本生成 undo log（undo log 也会产生 redo log 来保证 undo log 的可靠性）。

事务提交之后，undo log 并不能立马被删除，而是放入待清理的链表中，由 purge 线程来判断是否有其它事务在使用 undo 段中表的上一个事务之前的版本信息，从而决定是否可以清理 undo log 的日志空间。

数据库事务的四大特性中有一个是原子性，具体来说原子性是指对数据库的一系列操作，要么全部成功，要么全部失败，不可能出现部分成功的情况。

实际上，原子性底层就是通过 undo log 实现的。

undo log 主要记录了数据的逻辑变化，比如一条 insert 语句，对应着一条 delete 的 undo log；一条 update 语句，对应着一条相反的 update 的 undo log。这样在发生错误时，就能回滚到事务之前的数据状态。

在这里插入图片描述

执行update user set name = 'xiaohong' where id = 1的时候生成的 undo log 大概是update user set name = 'xiaoming' where id = 1。

同时，undo log 也是 MVCC（多版本并发控制）实现的关键。

MySQL 是如何保证事务的持久性的呢？

最简单的做法是在每次事务提交的时候，都将该事务涉及到修改的数据页全部刷新到磁盘中。但是这样做会有严重的性能问题，主要体现在两个方面：

因此，MySQL 设计了 redo log 机制，并通过 WAL（Write-Ahead Logging）技术进行了性能优化。

WAL 的核心就是先顺序 I/O 写日志磁盘、再随机 I/O 写数据磁盘，节省的是随机写磁盘的 I/O 消耗。

MySQL 每执行一条 DML 语句，先将记录顺序追加写入 redo log buffer 并更新内存中的数据，等到有空闲线程、内存不足或者 redo log 满时再批量落盘实现持久化。

binlog 是 MySQL 的逻辑日志并且由 Server 层进行记录，记录对象为任意数据库引擎的写入性操作（不包括查询）信息，以二进制的形式保存在磁盘中。

在实际应用中，binlog 的主要使用场景有两个：

万一在更新数据的过程中系统出现故障异常重启了，那么如何保证事务的持久性、原子性呢？

概述如下：

在这里插入图片描述

基于上述简化版的 undo log、redo log 和 binlog 的写入流程，我们来梳理下原子性、持久性、一致性的可靠性保证：

假如在步骤 1/2/3 中任一步骤发生故障，故障恢复后发现 redo log 中并无未完成的记录，故障恢复后只需要回滚 undo log 恢复现场即可
假如在步骤 4/5 中任一步骤发生故障，故障恢复后发现 redo log 处于 prepare 状态，则需要进一步判断是否已经写入 binlog，若已经写入 binlog，则重新执行 redo log 的相关记录直到成功并达到 commit 状态（主从的一致性）；若未写入 binlog，则回滚 undo log 恢复现场（原子性）
假如在步骤 6 发生故障，故障恢复后发现 redo log 处于 commit 状态，表示过程全部正常完成，什么都不需要做

关注

专栏目录