Mysql日志undo redo binlog与更新一条数据的执行过程详解
参考
https://xiaolincoding.com/mysql/log/how_update.html
https://blog.csdn.net/qq_39390545/article/details/115214802
https://javaguide.cn/database/mysql/mysql-logs.html#%E5%88%B7%E7%9B%98%E6%97%B6%E6%9C%BA
https://blog.csdn.net/weixin_42029860/article/details/138962150
https://baijiahao.baidu.com/s?id=1821334254098820619&wfr=spider&for=pc
https://www.cnblogs.com/ScarecrowAnBird/p/18163444
https://blog.51cto.com/u_16213622/12478907
https://blog.csdn.net/weixin_42029860/article/details/138962150
介绍
日志种类
MySQL日志主要包括以下几种：
- 回滚日志（undo log）
- 重做日志（redo log）
- 归档日志（binlog）
- 错误日志（errorlog）
- 慢查询日志（slow query log）
- 一般查询日志（general log）
- 中继日志（relay log）
其中，前三种比较重要，涉及数据库的acid，而后面几种相对不这么重要
大概介绍
回滚日志undo log 主要用于回滚与事务的隔离性和mvcc实现
重做日志redo log和binlog 可以
更新数据的过程
具体更新一条记录 UPDATE t_user SET name = 'xiaolin' WHERE id = 1; 的流程如下:
- 执行器负责具体执行，会调用存储引擎的接口，通过主键索引树搜索获取 id = 1 这一行记录：
- 如果 id=1 这一行所在的数据页本来就在 buffer pool 中，就直接返回给执行器更新；
- 如果记录不在 buffer pool，将数据页从磁盘读入到 buffer pool，返回记录给执行器。
- 执行器得到聚簇索引记录后，会看一下更新前的记录和更新后的记录是否一样：
- 如果一样的话就不进行后续更新流程；
- 如果不一样的话就把更新前的记录和更新后的记录都当作参数传给 InnoDB 层，让 InnoDB 真正的执行更新记录的操作；
- 开启事务： InnoDB 层更新记录前，首先要记录相应的 undo log，因为这是更新操作，需要把被更新的列的旧值记下来，也就是要生成一条 undo log，undo log 会写入 Buffer Pool 中的 Undo 页面，不过在内存修改该 Undo 页面后，需要记录对应的 redo log。
- InnoDB 层开始更新记录，会先更新内存（同时标记为脏页），然后将记录写到 redo log 里面，这个时候更新就算完成了。为了减少磁盘I/O，不会立即将脏页写入磁盘，后续由后台线程选择一个合适的时机将脏页写入到磁盘。这就是 WAL 技术，MySQL 的写操作并不是立刻写到磁盘上，而是先写 redo 日志，然后在合适的时间再将修改的行数据写到磁盘上。
- 在一条更新语句执行完成后，然后开始记录该语句对应的 binlog，此时记录的 binlog 会被保存到 binlog cache，并没有刷新到硬盘上的 binlog 文件，在事务提交时才会统一将该事务运行过程中的所有 binlog 刷新到硬盘。
- 接下来是开始事务提交阶段：为了方便说明，这里不说组提交的过程，只说两阶段提交）：
prepare 阶段：将 redo log 对应的事务状态设置为 prepare，然后将 redo log 刷新到硬盘；
commit 阶段：将 binlog 刷新到磁盘，接着调用引擎的提交事务接口，将 redo log 状态设置为 commit（将事务设置为 commit 状态后，刷入到磁盘 redo log 文件）； - 至此，一条更新语句执行完成。
redolog
记得小时候看《武林外传》，吕秀才柜台下面有一个小黑板，当时不知道是干啥的，后来发现是专门用来记录客人的赊账记录。如果赊账的人不多，那么他可以把顾客名和账目写在板上。但如果赊账的人多了，小黑板没地儿了，这个时秀才一定还有一个专门记录赊账的账本。如果有人要赊账或者还账的话，秀才一般有两种做法：
一种做法是直接把账本翻出来，把这次赊的账加上去或者扣除掉；
另一种做法是先在小黑板上记下这次的账，等打烊以后再把账本翻出来核算。
在生意火爆时，秀才肯定会选择后者，因为直接记账本太麻烦了。得先翻出赊账人“老钱”那条记录，账本密密麻麻几十页，找到后再拿出算盘计算，最后更新到账本上。想想都麻烦。相比之下，还是先在小黑板上记一下方便。你想想，如果秀才没有小黑板的帮助，每次记账都得翻账本，效率是不是低得让人难以忍受？还有时间泡小郭？想无双？
同样，在 MySQL 里也有这个问题，如果每一次的更新操作都需要写进磁盘，然后磁盘也要找到对应的那条记录，然后再更新，整个过程 IO 成本、查找成本都很高。为了解决这个问题，MySQL 的设计者就用了类似秀才记小黑板的思路来提升更新效率。
而小黑板和账本配合的过程，其实就是 MySQL 里经常说到的 WAL 技术。
WAL
WAL 的全称是 Write-Ahead Logging，它的关键点就是先写日志，再写磁盘，也就是先写小黑板，等不忙的时候再写账本。
好处是提高性能。
具体来说，当有一条update语句要执行的时候，InnoDB 引擎就会先把记录写到 redo log（小黑板）里面，并更新内存，这个时候更新就算完成了。
同时，InnoDB引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做，这就像打烊以后秀才做的事。如果今天赊账的不多，掌柜可以等打烊后再整理。但如果某天赊账的特别多，小黑板写满了咋办？这个时候秀才只好叫无双帮忙干自己的活儿，抓紧把小黑板中的一部分赊账记录更新到账本中，然后把这些记录从小黑板上擦掉，为记新账腾出空间。
与此类似，InnoDB 的 redo log 是固定大小的，比如可以配置为一组 4 个文件，每个文件的大小是 100MB，那么这块“小黑板”总共就可以记录 400MB 的操作记录。从头开始写，写到末尾就又回到开头循环写，如下面这个图所示。
有了 redo log，InnoDB 就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为 crash-safe。
持久性 crash-safe：
可以对照前面赊账记录的例子。只要赊账记录记在了小黑板上或写在了账本上，即使秀才突然被老邢抓走几天，回来后依然可以通过账本和小黑板上的数据明确赊账账目。就是维护数据的持久性。
本质上说，crash-safe 就是落盘处理，将数据存储到了磁盘上，断电重启也不会丢失。
为什么还要有bin log
MySQL为啥要有redo log 和 binlog两个日志呢？只留一个不香么？
熊猫：因为最开始 MySQL 里并没有 InnoDB 引擎。MySQL 自带的引擎是 MyISAM，但是 MyISAM 没有 crash-safe 的能力，而 binlog 日志只用于归档。
InnoDB 是另一个公司以插件形式引入 MySQL 的。我们知道，只依靠 binlog 是没有 crash-safe 能力的，所以 InnoDB 使用另外一套日志系统——也就是 redo log 来实现 crash-safe 能力。
面试官：那这两个日志主要有哪些区别？
熊猫：emmm…主要有几下几种区别：
redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎共用。
redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=1 这一行的 c 字段加 1 ”。
redo log 是循环写的，空间固定会用完然后复写；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。