一张图让你看懂InnoDB存储引擎

原文连接:

https://baijiahao.baidu.com/s?id=1589223384392431089&wfr=spider&for=pc



InnoDB存储引擎体系架构

熟悉 MySQL 的人,都知道 InnoDB 存储引擎,如大家所知,Redo Log 是innodb 的核心事务日志之一,innodb 写入 Redo Log 后就会提交事务,而非写入到 Datafile。之后 innodb再异步地将新事务的数据异步地写入 Datafile,真正存储起来。那么 innodb 引擎有了 redo log 和 buffer pool 以后,为什么能够在提升性能的同时,还能保证不丢数据呢? Buffer Pool, Redo Log 以及 Datafile 之间的具体关系是什么呢。

另外 Innodb 还有一大堆概念,Dirty Page, LRU(Least Recently Used,最近最少使用移除,缓存淘汰算法), LSN(日志序号 (LSN:Log sequence number) 标识特定日志文件记录在日志文件中的位置),Checkpoint 等等,这些概念在 Innodb 里是什么运作的呢?下面通过一张图来告诉大家Buffer Pool, Redo Log 以及 Datafile 的关系


Buffer Pool, Redo Log 以及 Datafile 的关系

大家可以把 innodb 的事务写入过程看成写作一篇文章的过程。Innodb 的写入过程其实和我们写作的过程是非常类似的。试想,领导让我们写一篇文章,发表在论坛上。然后我们想到了一个绝佳的点子,并决定要放到文章里,可是手上还有其他事情,一时半会儿写不完,又担心过后忘了,领导还等着我们答复,此时我们会怎么做呢?我们一定会先大概构思个提纲,并把提纲和一些关键细节记录到本子上,作为草稿,然后立刻告诉领导自己要写什么东西,让其确认。最后等晚上有时间了,再根据草稿去斟词酌句,编写正稿。

在这个过程中,我们用到的几个关键的东西:


我们的大脑,用来临时暂时记住我们的点子

草稿,我们需要草稿来保证不会把点子和关键的细节给忘了

正稿,这是我们最终要输出的东西


有了这几个东西,我们不仅能确保我们不会错过一篇漂亮的文章,还能快速告诉领导自己一定可以搞定这件事情。

Innodb 实际上也用到了这几个关键的东西:


Buffer Pool:就是我们的大脑

事务日志:就是我们的草稿

Datafile:就是我们的正稿


只要按照之前写文章的过程,来进行整个事务的写入操作,不仅能保证不丢失数据,而且能够快速响应。

一次写入操作是一次事务,innodb

首先把事务数据写入到 Buffer Pool 和事务日志中,也就是在大脑中记忆下来,并写下草稿。然后就可以提交事务,响应客户端了。之后innodb 在 “有时间的时候”,异步地把这次写入的数据从 Buffer Pool,或者事务日志中正式地写入到 Datafile 中,形成“正稿”。其中,innodb 为了保证事务日志这个 “草稿” 一定能无损地还原成正稿,还不能占用太多空间,事务日志需要有以下特点:事务日志中一定保存了要写入的所有数据内容事务日志只会把新事务追加在日志最后,而不会去修改之前的内容一旦事务数据被写到 datafile,事务日志中的 “草稿” 就可以删除了

通过上面 3 个特点我们可以看出,在形成 “正稿” 之前,“草稿” 是不会被删除的;同时,“草稿” 的空间是可以被循环利用的;最后,只要 “草稿” 在,我们一定能写出 “正稿”。这里还需要说明的,是Recovery 流程。也就是如果在形成 “正稿” 前,数据库 Crash了,我们需要重启整个进程,服务器,甚至只能把数据复制到另外一台服务器来进行恢复。这个时候,事务日志这个 “草稿”就发挥了它最大的作用——数据恢复。这也和我们在工作生活中常出现的问题——把事情忘了——非常类似。Buffer Pool 本质就是存储于内存中的一个数据结构,内存和人的大脑一样,是 “健忘” 的。数据库 Crash 时,Buffer Pool中的数据极大可能 “灰飞烟灭” 了。因此,事务日志就如我们贴心的 “记事本”,它把我们的记忆,保存为“草稿”,当我们忘了的时候,就可以翻开,把记忆重新回想起来。


数据如何恢复

LSN 和 Checkpoint

上面介绍了一次写入事务的情况,而数据库在使用过程中,事务都是连续不断,根据上面所述 innodb 逻辑,写 “草稿” 和写 “正稿” 速度和进度绝大部分情况下是不一样的。

再继续上面 “写作文章” 例子,如果我们的文章很长,一天写不完,而白天都有其他工作,我们只能记录草稿,只有晚上回去才能继续写正稿。那么我们就面临一个问题:我们昨天写到哪了。

最常见的办法就是,每天晚上去对照一下草稿的内容和正稿的内容,以此来判断写到哪了,但这比较花时间,因为正稿中可能包含了很多华丽的语句,我们需要思考一下才能对比上内容。

另外一个更简单的办法,就是每天晚上写完正稿后,我们在草稿上做个标记,标记下最后一条被写为正稿的内容,这样第二天晚上,我们就可以从这个标记的后面一条开始,继续写我们的正稿,而不需要去对比内容。显然第二个方法效率更高,而且没有什么额外的风险。因此innodb 就使用了这个办法。LSN 是草稿上每一条记录的编号,我们每天晚上标记下最后一条写到正稿的记录编号,这个标记的编号,就是Checkpoint。Innodb 根据这个 checkpoint,就可以很快知道上次回放到哪里,同时也可以把这个编号之前的草稿,全部删掉了。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 155,623评论 4 358
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 66,044评论 1 285
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 105,482评论 0 236
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,350评论 0 201
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 51,666评论 3 285
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,130评论 1 204
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,525评论 2 306
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,247评论 0 193
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,870评论 1 235
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,211评论 2 239
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,753评论 1 255
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,116评论 2 249
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,639评论 3 228
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,929评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,634评论 0 191
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,141评论 2 262
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,089评论 2 257

推荐阅读更多精彩内容