20说过的话就一定要办到 —— redo 日志（上）(02).pdf
免费下载
redo⽇志（上）
标签： MySQL是怎样运⾏的
事先说明
本⽂以及接下来的⼏篇⽂章将会频繁的使⽤到我们前边唠叨的
InnoDB记录⾏格式、⻚⾯格式、索引原理、表空间的组成等各种基
础知识，如果⼤家对这些东⻄理解的不透彻，那么阅读下边的⽂字可
能会有些吃⼒，为保证您的阅读体验，请确保⾃⼰已经掌握了我前边
唠叨的这些知识。
redo⽇志是个啥
我们知道InnoDB存储引擎是以⻚为单位来管理存储空间的，我们进
⾏的增删改查操作其实本质上都是在访问⻚⾯（包括读⻚⾯、写⻚
⾯、创建新⻚⾯等操作）。我们前边唠叨Buffer Pool的时候说
过，在真正访问⻚⾯之前，需要把在磁盘上的⻚缓存到内存中的
Buffer Pool之后才可以访问。但是在唠叨事务的时候⼜强调过⼀
个称之为持久性的特性，就是说对于⼀个已经提交的事务，在事务提
交后即使系统发⽣了崩溃，这个事务对数据库中所做的更改也不能丢
失。但是如果我们只在内存的Buffer Pool中修改了⻚⾯，假设在
事务提交后突然发⽣了某个故障，导致内存中的数据都失效了，那么
这个已经提交了的事务对数据库中所做的更改也就跟着丢失了，这是
我们所不能忍受的（想想ATM机已经提示狗哥转账成功，但之后由
于服务器出现故障，重启之后猫爷发现⾃⼰没收到钱，猫爷就被砍死
了）。那么如何保证这个持久性呢？⼀个很简单的做法就是在事务提
交完成之前把该事务所修改的所有⻚⾯都刷新到磁盘，但是这个简单
粗暴的做法有些问题：
刷新⼀个完整的数据⻚太浪费了
有时候我们仅仅修改了某个⻚⾯中的⼀个字节，但是我们知道
在InnoDB中是以⻚为单位来进⾏磁盘IO的，也就是说我们在
该事务提交时不得不将⼀个完整的⻚⾯从内存中刷新到磁盘，
我们⼜知道⼀个⻚⾯默认是16KB⼤⼩，只修改⼀个字节就要刷
新16KB的数据到磁盘上显然是太浪费了。
随机IO刷起来⽐较慢
⼀个事务可能包含很多语句，即使是⼀条语句也可能修改许多
⻚⾯，倒霉催的是该事务修改的这些⻚⾯可能并不相邻，这就
意味着在将某个事务修改的Buffer Pool中的⻚⾯刷新到磁
盘时，需要进⾏很多的随机IO，随机IO⽐顺序IO要慢，尤其对
于传统的机械硬盘来说。
咋办呢？再次回到我们的初⼼：我们只是想让已经提交了的事务对数
据库中数据所做的修改永久⽣效，即使后来系统崩溃，在重启后也能
把这种修改恢复出来。所以我们其实没有必要在每次事务提交时就把
该事务在内存中修改过的全部⻚⾯刷新到磁盘，只需要把修改了哪些
东⻄记录⼀下就好，⽐⽅说某个事务将系统表空间中的第100号⻚⾯
中偏移量为1000处的那个字节的值1改成2我们只需要记录⼀下：
将第0号表空间的100号⻚⾯的偏移量为1000处的值更
新为2。
这样我们在事务提交时，把上述内容刷新到磁盘中，即使之后系统崩
溃了，重启之后只要按照上述内容所记录的步骤重新更新⼀下数据
⻚，那么该事务对数据库中所做的修改⼜可以被恢复出来，也就意味
着满⾜持久性的要求。因为在系统奔溃重启时需要按照上述内容所记
录的步骤重新更新数据⻚，所以上述内容也被称之为重做⽇志，英⽂
of 27
免费下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
下载排行榜
文档被以下合辑收录
评论