mysql中InnoDB引擎中页的概念

Innodb中页的概念

基础结构

Page是Innodb存储的最基本结构,也是Innodb磁盘管理的最小单位,与数据库相关的所有内容都存储在Page结构里。Page分为几种类型:数据页(B-Tree Node)Undo页(Undo Log Page)系统页(System Page)事务数据页(Transaction System Page)等;每个数据页的大小为16kb,每个Page使用一个32位(一位表示的就是0或1)的int值来表示,正好对应Innodb最大64TB的存储容量(16kb * 2^32=64tib)
一个Page的基本结构如下:

clipboard.png

头部数据

每个page都有通用的头和尾,但是中部的内容根据page的类型不同而发生变化,头部的数据如下:

clipboard.png

page头部保存了两个指针,分别指向前一个Page和后一个Page,头部还有Page的类型信息和用来唯一标识Page的编号。根据这个指针分布可以想象到Page链接起来就是一个双向链表

clipboard.png

主体数据

在Page的主体部分,主要关注数据和索引的存储,他们都位于User Records部分,User Records占据Page的大部分空间,User Records由一条条的Record组成,每条记录代表索引树上的一个节点(非叶子节点和叶子节点);在一个单链表的内部,单链表的头尾由两条记录来表示,字符串形式的“ Infimum”代表开头,“Supremum”表示结尾;System Record 和 User Record是两个平行的段;
Innodb中存在四种不同的Record,分别是

  1. 主键索引树非叶子节点

  2. 主键索引树叶子节点

  3. 辅助键索引树非叶子节点

  4. 辅助键索引树叶子节点

这四种节点Record格式上有差异,但是内部都存储着Next指针指向下一个Record

clipboard.png

User Record

User Record在Page内以单链表的形式存在,最初数据是按照插入的先后顺序排列的,但是随着新数据的插入和旧数据的删除,数据物理顺序发生改变,但是他们依然保持着逻辑上的先后顺序

clipboard.png

把User Record组织形式和若干Page组织起来,就得到了稍微完整的形式:

clipboard.png

如何定位一个Record:
  1. 通过根节点开始遍历一个索引的B+树,通过各层非叶子节点达到底层的叶子节点的数据页(Page),这个Page内部存放的都是叶子节点

  2. 在Page内部从“Infimum”节点开始遍历单链表(遍历一般会被优化),如果找到键则返回。如果遍历到了“Supremum”,说明当前Page里没有合适的键,这时借助Page页内部的next page指针,跳转到下一个page继续从“Infmum”开始逐个查找

clipboard.png

User Record内部的数据

User Record内部存储了四种格式的数据:

  1. 主索引树非叶子节点(绿色)

    • 子节点存储的主键里最小的值,这时B+树必须的,作用是在一个Page里定位到具体的记录的位置

    • 最小的值所在的Page的编号,作用是定位到对应的Record所在的Page

  2. 主索引树叶子节点(黄色)

    • 主键,B+树所必须的,也是数据行的一部分

    • 除去主键以外的所有列,这时数据行的除去主键的其他所有列的集合

  3. 辅助索引树非叶子节点(蓝色)

    • 子节点里存储的辅助键值里的最小值,这时B+Tree必须的,作用是在一个Page里定位到具体记录的位置

  4. 辅助索引树叶子节点(红色)

    • 辅助索引键值,是B+树必须的

    • 主键值,用来在主索引树里在做一次B+树检索来找到整条记录

clipboard.png

整体的查找过程

clipboard.png

简介的树形查找示意图

clipboard.png

Page和B+树之间并没有一一对应的关系,Page只是作为一个Record的保存容器,它存在的目的是便于对磁盘空间进行批量管理。


坏掉的大门牙
如发现表达不明确或错误的地方请及时指正

自己笔记中的内容更新在这里,对一些内容的理解可能存在偏差,希望有什么理解不对的能及时被指出来?

336 声望
14 粉丝
0 条评论
推荐阅读
关于php trim方法的错误理解导致的问题
下面的例子中只以ltrim方法做举例在我之前的认知中(当然我很水,从没看过这块源码),如果我想要删除字符串左边的空字符串,空制表符之类的,那么我就直接使用ltrim($str)即可

坏掉的牙2阅读 3.7k

分布式高可用Mysql数据库Percona XtraDB Cluster 8.0 与 Proxysql 史上最详尽用法指南
PXC是Percona XtraDB Cluster的缩写,是 Percona 公司出品的免费MySQL集群产品。PXC的作用是通过mysql自带的Galera集群技术,将不同的mysql实例连接起来,实现多主集群。在PXC集群中每个mysql节点都是可读可写的...

apollo0084阅读 7.2k评论 2

一次偶然机会发现的MySQL“负优化”
今天要讲的这件事和上述的两个sql有关,是数年前遇到的一个关于MySQL查询性能的问题。主要是最近刷到了一些关于MySQL查询性能的文章,大部分文章中讲到的都只是一些常见的索引失效场合,于是我回想起了当初被那个...

骑牛上青山5阅读 1.1k评论 3

MongoDB 插入时间与更新时间(create_time/update_time)
MongoDB 在数据库层面不能像 MySQL 一样设置自动创建 create_time/update_time,自动更新 update_time

qbit阅读 13.8k评论 2

Mysql索引覆盖
通常情况下,我们创建索引的时候只关注where条件,不过这只是索引优化的一个方向。优秀的索引设计应该纵观整个查询,而不仅仅是where条件部分,还应该关注查询所包含的列。索引确实是一种高效的查找数据方式,但...

京东云开发者2阅读 656

封面图
SegmentFault 思否技术周刊 Vol.70 — 深入 MySQL 实战
MySQL 软件采用了 GPL( GNU 通用公共许可证),由于其体积小、速度快、总体拥有成本低,尤其是开放源码这一特点,许多中小型网站为了降低网站总体拥有成本而选择了 MySQL 作为网站数据库。

Beverly2阅读 1.4k

封面图
MySQL 数据库索引技术原理初探
一本书 500 页的书,如果没有目录,直接去找某个知识点,可能需要找一会儿,但是借助前面的目录,就可以快速找到对应知识点在书的哪一页。这里的目录就是索引。

mylxsw1阅读 1.2k

自己笔记中的内容更新在这里,对一些内容的理解可能存在偏差,希望有什么理解不对的能及时被指出来?

336 声望
14 粉丝
宣传栏