结合MySQL更新流程看 undolog、redolog、binlog

前言

看过我之前文章《一条Update语句的执行过程是怎样的？》的朋友都基本知道【点击文章传送门~🙌】，在整个Update更新语句中会涉及到三种日志，分别是undo log(回滚日志）、redo log (重做日志) 、binlog (归档日志)，也有两阶段提交，没看过的不要紧，可以结合本篇文章一起看，会有1+1>2的效果。

当时我们在文末也留了个小目标，就是更新一期详细分享下三种日志的用处和产生的时机等知识，进行更深一步的扩展，刚好现在这个时候。

Let’s Go！，额，最近听《My Stupid Heart》🎵🎵🎵上头了，经常浮现Let’s Go开头了，感兴趣的朋友可以去听下这首歌。

好了，回归正题，正文正式开始！📄📄

📚 全文字数 : 9k+

⏳ 阅读时长 : 13min

📢 关键词 : undolog、redolog、binlog

开篇tip

我们知道日志的作用不言而喻，无论是线上排查，亦或是性能优化，几乎都需要从日志中来获得信息作为依据，而MySQL中，很多很多的功能也都需要基于日志实现，比如事务回滚、数据持久化、数据恢复、数据迁移、MVCC机制…

我们在了解具体内容之前，先对三种日志之间的小总结，涉及到使用场景和文件等，可以把这个当做先前总结，更细的内容在每一章会提及。

简单梳理下日志是在哪个地方写入到不同日志文件中的，undolog、redolog都是InnoDB引擎中的日志，而且都是在Buffer Pool中，而binlog在Server层中，位于每条线程中，并且每种日志在磁盘中的的归档方式和文件都是不一样的，之间的区别如下图。

WAL机制是什么？

WAL，全称是Write-Ahead Logging， 预写日志系统。指的是 MySQL 的写操作并不是立刻更新到磁盘上，而是先记录在日志上，然后在合适的时间再更新到磁盘上。

MySQL真正使用WAL的原因是：磁盘的写操作是随机IO，比较耗性能，所以如果把每一次的更新操作都先写入log中，那么就成了顺序写操作，实际更新操作由后台线程再根据log异步写入。

这样对于client端，延迟就降低了。并且，由于顺序写入大概率是在一个磁盘块内，这样产生的IO次数也大大降低。所以WAL的核心在于将随机写转变为了顺序写，降低了客户端的延迟，提升了吞吐量。

CheckPoint技术是啥？

在MySQL中主要是将缓冲池中的脏页刷回到磁盘。InnoDB存储引擎内部，两种checkpoint，分别为:Sharp Checkpoint 和 Fuzzy Checkpoint。

而MYSQL中主要是为了保证数据会做很多CheckPoint动作

Undo log

undo log 叫做回滚日志，它保证了事务的 ACID 特性中的原子性（Atomicity），是引擎层生成的日志，记录的是逻辑操作，用于记录数据被修改前的信息，这里的逻辑操作是指： “增（insert）删（delete）改（update）”。

undo log的两个主要作用是【事务回滚】 和 通过ReadView + undo log 实现 【MVCC (多版本并发控制)】

记录内容

不同的SQL修改操作，记录的undo log分别是什么呢？

insert 插入操作，会在undo log中记录本次插入的主键id，等事务回滚时，会delete此主键对应的记录，

update 更新操作，会记录一条相反的update的undo log，回滚时执行一次相反update，更新回原来的数据，

delete 删除操作，会记录删除前的数据，回滚时，insert原来的数据。

通过上面的相反逻辑处理，这样的话即使发生错误时，就能回滚到事务之前的数据状态。

一条SQL没有begin开启事务和Commit提交事务，也能自己提交事务？

是的，MYSQL事务分为【隐式事务和显示事务】

隐式事务：

比如insert、update、delete语句，事务的开启、提交或回滚由mysql内部自动控制的，事务自动开启、提交或回滚。

我们可以通过 show variables like 'autocommit’查看是否开启了自动提交，autocommit为ON表示开启了自动提交

显示事务:

显式事务是指在应用程序中明确指定事务的开