学习mysql8-redo日志

redo-log的内容和作用

数据丢失

我们在之前的buffer-pool的内容中提到过，数据的增删改查大概率的情况下，是在内存里面完成的。之后会从bufferPool不定期的刷新脏页到磁盘上，这样的一个过程会导致什么样的问题呢？
如果buffer-pool修改的内容，在发生断电或者系统崩溃的情况下，是不是就导致所有修改的内容丢失了呢。

redo-log如何力挽狂澜

那么如何才能保证所有的数据能从buffer-pool同步到磁盘上呢？
当然最简单的方式就是每次修改了数据，都及时的同步到磁盘上，按这么解决，保证了数据的一致性，牺牲的就是时间。每一次更新修改或者一个事务的提交，都需要耗费很多时间。
为此Mysql特意设计了redo日志，用来防止系统崩溃导致的数据丢失。redo日志专门用于记录buffer-pool和磁盘上不一致的一些内容，如果说不是为了恢复而使用，反而浪费了空间和时间。
redo⽇志占⽤的空间⾮常⼩，记录了存储表空间ID、页号、偏移量以及需要更新的值所需的存储空间。redo⽇志是顺序写⼊磁盘的，如果说一个事务修改了多项内容，也是顺序IO的写入。

redo-log的格式

通过上边的内容我们知道，redo⽇志本质上只是记录了⼀下事务对数据库做了哪些修改。 设计InnoDB的⼤叔们针对事务对数据库的不同修改场景定义了多种类型的redo⽇志，但是绝⼤部分类型的redo⽇ 志都有下边这种通⽤的结构

type表示的是redolog的类型，目前记录了有53种。space ID表空间ID，page number表示了数据页号，data是记录了实际改动的数据

简单日志结构

row_id : 多次讲到过隐藏列的这个属性用来做主键的，如果递增到256的倍数的时候，会记录在系统表空间页号为7的页⾯的相应偏移量处 写⼊8个字节的值，如果发生断电的情况下，下次row_id的值就是改处的值+256。
我们把这种只对修改了几个字节的redoLog归类成简单日志，如下：
MLOG_1BYTE（type字段对应的⼗进制数字为1）：表⽰在页⾯的某个偏移量处写⼊1个字节的redo⽇志类型。
MLOG_2BYTE（type字段对应的⼗进制数字为2）：表⽰在页⾯的某个偏移量处写⼊2个字节的redo⽇志类型。
MLOG_4BYTE（type字段对应的⼗进制数字为4）：表⽰在页⾯的某个偏移量处写⼊4个字节的redo⽇志类型。
MLOG_8BYTE（type字段对应的⼗进制数字为8）：表⽰在页⾯的某个偏移量处写⼊8个字节的redo⽇志类型。
MLOG_WRITE_STRING（type字段对应的⼗进制数字为30）：表⽰在页⾯的某个偏移量处写⼊⼀串数据。


主要的区别就是在data这里：你也可以提出疑惑难道len为1，2，3，4的不就是上面对应的哪些类型吗，其实是对的。但是设计的人考虑到节省空间，用type就制定了对应的标准

复杂的日志结构

有时候执⾏⼀条语句会修改⾮常多的页⾯，包括系统数据页⾯和⽤户数据页⾯（⽤户数据指的就是聚簇索引和⼆级索引对应的B+树）。以⼀条INSERT语句为例，它除了要向B+树的页⾯中插⼊数据，也可 能更新系统数据Max Row ID的值。
⽐⽅说将记录插⼊到聚簇索引中时，如果定位到的叶⼦节点的剩余空间⾜够 存储该记录时，那么只更新该叶⼦节点页⾯就好，那么只记录⼀条MLOG_WRITE_STRING类型的redo⽇志，表明在页⾯的某个偏移量处增加了哪些数据就好了么？那就too young too naive了～ 别忘了⼀个数据 页中除了存储实际的记录之后