InnoDB体系架构

InnoDB是MySQL数据库中最常用的存储引擎,InnoDB的体系架构如下图所示:
InnoDB体系架构

InnoDB体系架构主要包含三部分:后台线程,缓冲池,文件。

(一)后台线程

InnoDB使用多线程模型,后台线程主要分为四个线程:

  • Master Thread: 最核心的一个线程,用于异步刷新缓冲页到磁盘,保证数据一致性;

  • IO Thread: InnoDB中使用了大量异步IO来处理IO请求,该线程主要负责这些IO请求的回调;

  • Purge Thread: 该线程用来回收无用的undo页,InnoDB支持多个Purge线程回收undo页;

  • Page Cleaner Thread: 负责脏页刷新到磁盘的操作,异步刷新;

    (二)缓冲池

    InnoDB存储引擎是基于磁盘存储的,由于磁盘和CPU之间速度的鸿沟,InnoDB使用缓冲池来提高性能。InnoDB的数据存储都是以页为维度的,缓冲池中主要存放:

    • 数据页

    • 索引页

    • undo页

    • Change Buffer页

    • 自适应哈希索引

    • 锁信息

    • 数据字典信息

    • redo日志

    (三)磁盘文件

    InnoDB存储引擎是基于磁盘的,所有的数据都存放在磁盘文件中,后续会分析数据如何存储?

    InnoDB存储结构

    InnoDB中每张表都有主键,如果没有显示的定义主键,会选择一个非空的唯一索引来做为主键;如果没有,则自动创建一个6字节大小的指针做主键。

    本篇文章基于的是MySQL5.7版本之后,因此一些弃用的特性就不介绍了,比如frm文件要来保存表结构元数据信息等。

    下文通过InnoDB逻辑存储结构和物理存储结构综合来介绍,主要解决下面两个问题:

    • InnoDB逻辑上是怎么组织数据的???

    • InnoDB逻辑上设计的存储结构怎么落地到物理存储上的???

    逻辑&物理存储结构

    InnoDB中所有数据都被存放在一个空间中,称之为“表空间(tablespace)”;表空间又由段(segment)、区(extent)、页(page)组成。

    先上图,InnoDB的逻辑存储结构如下图所示:
    逻辑存储结构

    从图中可以看出,他们的层级关系是一对多,下面逐步介绍各个层级的逻辑结构!

    1. 表空间——Tablespace

    表空间可以看做是InnoDB逻辑存储结构的最高层级;所有的数据都是存放在表空间中的。默认情况下,InnoDB的所有数据都存放在共享表空间中ibdata1;当用户设置参数innodb_file_per_table时,InnoDB会为每个表产生一个独立的表空间。

    独立的表空间中只存放数据,索引和Change Buffer;而其余的undo信息,事务信息,Double Write等还在共享表空间中。

    (一)共享表空间

    共享表空间又叫做系统表空间(System Tablespace),默认的文件名为ibdata1。可以通过innochecksum --page-type-summary ibdata1命令查看共享表空间中存放了哪些文件类型。

    共享表空间文件类型

    innodb_file_per_table参数开启后,共享表空间中的数据页(data page)移到了独立表空间中。ibdata1文件的初始大小为12M,磁盘上的文件都是以二进制的形式存储。在ibdata1文件中顺序的存放着不同种类的page。

    由于初始大小为12M,当保存的page信息增多时,共享表空间会继续生成新的文件来增长空间,比如ibdata2,ibdata3等等。当共享表空间暴增的时候会导致InnoDB的性能变差,那么何时会导致共享表空间大小暴增??? 共享表空间中主要保存了undo信息和Change Buffer信息;因此大小暴增主要有下面两个原因:

    • 大事务,产生大量的undo页;

    • 索引建立过多,导致Change Buffer暴增;

    解决办法 对于大事务的undo页信息,InnoDB提供了解决办法,可以在共享表空间初始化的时候讲undo页分离出去;参数innodb_undo_tablespaces可以设置undo表空间的个数,后续所有的undo信息会保存在单独的undo表空间中。

    共享表空间存储结构

    共享表空间存储结构

    具体的字节的详细含义此处略过,大体的结构如图所示。

    优点 表大小可以无限增大,可以跨文件存储,不同的文件可以存储在不同的磁盘上。 缺点 所有表的数据存放在一起,不易区分;当表删除回收后,会产生大量的空间碎片。

    (二)独立表空间

    基于上述共享表空间的缺点,InnoDB支持为每个表建立一个独立表空间文件,文件名为"表名.ibd"。

    独立表空间存储结构

    独立表空间存储结构

    优点 每个表独立存储自身的数据和索引,方便不同数据库的迁移;表被回收后,不影响其他表;表内的空间碎片相对较少。 缺点 单表的空间增长过大会导致存储空间不足,需要从操作系统层面来解决。

    2. 段——Segment

    从逻辑结构图中可以看出,表空间包含多个段,其中最主要的是:

    • 数据段: B+树叶子节点;

    • 索引段: B+树非叶子节点;

    • 回滚段: 用来事务回滚;

      段存储结构 段在固定位置保存了区的元数据信息,其物理存储结构如下图所示:

      独立表空间存储结构

      3. 区——Extent

      区是由连续页组成的空间,为保证区中页的连续性,InnoDB会一次性的从磁盘申请4~5个区。区根据描述符来管理自身的页数据,其结构如下:

      区存储结构

      独立表空间存储结构

      4. 页——Page

      页是InnoDB最基本的结构,也是磁盘管理的最小单位。页主要有以下几种:

      • 数据页

      • 索引页

      • undo页

      • 系统页

      • 事务数据页

      这边主要讲解数据页和索引页,不说废话,先上图: 页存储结构

      页存储结构

      页主要包含页头(38个字节),页尾(8个字节)以及中间的body,这很类似网络中包的结构,页头中包含了页的基本信息,页尾中包含了页数据的一些校验,下面看下页头和页尾的具体结构:

      页头页尾存储结构

      页头页尾存储结构

      从页头中发现,每个页都有一个int类型唯一的id,代表页的偏移量,由于int类型4个字节,这也导致了页最大为64TB(2^{32});此外页头中还包含两个重要的指针:Previous Page Number和Next Page Number,分别指向前一页和后一页,这样我们就知道了,在一个B+树的节点里,不同的页是通过链表来顺序遍历的;页尾主要用于数据一致性校验,checksum来检查数据的完整性。

      头尾的存储都介绍完毕了,就剩下body存储数据,数据都是以行(Row)记录的形式存储;由于页内部空闲空间是随机分配的,以链表来组织,因此需要界定下记录的开始和结尾,因此body的部分一开始有两个系统定义的头尾记录指针:infimum和supremum,用来保存记录的首尾,其结构如下图所示:

      记录首尾存储结构

      记录首尾存储结构

      infimum记录从094开始,依次到120以supremum结束。那038094之前存储什么信息???

      主要存储的是索引头的信息,因为InnoDB中数据以B+树的形式存储。

      记录首尾相连的格式如下图:
      索引头存储结构

      索引头存储结构

      索引头存储结构

      里面的信息不详细展开了。

      5. 行——Row

      千呼万唤始出来,绕了半天,终于讲到了行(Row)记录的存储结构;InnoDB支持不同类型的行格式来存储数据,如下图:
      行格式

      其中Antelope是文件最开始支持的形式,后续增加了Barracuda的格式;其中最常用的是Compact,下面主要介绍Compact格式。
      Compact格式

      下面分析下各个字段的含义:

      • 变长字段长度列表: 主要用来存放变长字段的长度,逆序排列。

        举例: 字段VARCHAR(16),存储"abc",则变长长度为03;把所有变长字段的长度逆序排列;

        • NULL标志位: 标志列是否为null;

        • 记录头信息:
          记录头信息

        record_type记录类型,3bit,000表示普通页;001表示B+树节点;010表示infimum;011表示supremum;1xx保留。

        • 列值: 真实的数据;

          InnoDB会为每行数据添加隐藏的三个列值:

          1. DB_ROW_ID 行ID,唯一标识一条记录;
          1. DB_TRX_ID 事务ID;
          1. DB_ROLL_PTR 回滚指针;

          由于页有大小限制,当数据库中存储TEXT,BLOB等大型数据时,上述的列值不能完整的存放下所有的数据,这个时候怎么办??? InnoDB会生成一个BLOB的新页,然后在该列值上存放新页的地址来指向它。Compact格式会存储开头的768bytes。
          记录头信息

          总结

          本文主要介绍了InnoDB存储的逻辑结构和物理结构;说白了就是在文件中用链表实现了B+树;为了让计算机识别二进制数据,在记录的头部和尾部包装了各式各样的元信息;为了便于InnoDB各种关键特性的实现,又将头部尾部的元信息分层:segment,extent,page,row。 逻辑结构和物理结构的映射如下图:
          逻辑物理结构映射

          参考

          [1] MySQL技术内幕:InnoDB存储引擎
          [2] MySQL官方文档
          [3] 博客

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