InnoDB的数据页结构

页是InnoDB存储引擎管理数据库的最小磁盘单位。页类型为B-tree node的页,存放的即是表中行的实际数据了。

InnoDB数据页由以下七个部分组成,如图所示:

  1. File Header(文件头)。
  2. Page Header(页头)。
  3. Infimun+Supremum Records。
  4. User Records(用户记录,即行记录)。
  5. Free Space(空闲空间)。
  6. Page Directory(页目录)。
  7. File Trailer(文件结尾信息)。

File Header、Page Header、File Trailer的大小是固定的,用来标示该页的一些信息,如Checksum、数据所在索引层等。其余部分为实际的行记录存储空间,因此大小是动态的。

File Header

File Header用来记录页的一些头信息,由如下8个部分组成,共占用38个字节,如表4-3所示:

FIL_PAGE_SPACE_OR_CHKSUM:当MySQL版本小于MySQL-4.0.14,该值代表该页属于哪个表空间,因为如果我们没有开启innodb_file_per_table,共享表空间中可能存放了许多页,并且这些页属于不同的表空间。之后版本的MySQL,该值代表页的checksum值(一种新的checksum值)。

FIL_PAGE_OFFSET:表空间中页的偏移值。

FIL_PAGE_PREV,FIL_PAGE_NEXT:当前页的上一个页以及下一个页。B+Tree特性决定了叶子节点必须是双向列表。

FIL_PAGE_LSN:该值代表该页最后被修改的日志序列位置LSN(Log Sequence Number)。

FIL_PAGE_TYPE:页的类型。通常有以下几种,见表4-4。请记住0x45BF,该值代表了存放的数据页。

FIL_PAGE_FILE_FLUSH_LSN:该值仅在数据文件中的一个页中定义,代表文件至少被更新到了该LSN值。

FIL_PAGE_ARCH_LOG_NO_OR_SPACE_ID:从MySQL 4.1开始,该值代表页属于哪个表空间。

Page Header

接着File Header部分的是Page Header,用来记录数据页的状态信息,由以下14个部分组成,共占用56个字节。见表4-5。

PAGE_N_DIR_SLOTS:在Page Directory(页目录)中的Slot(槽)数。Page Directory会在后面介绍。

PAGE_HEAP_TOP:堆中第一个记录的指针。

PAGE_N_HEAP:堆中的记录数。

PAGE_FREE:指向空闲列表的首指针。

PAGE_GARBAGE:已删除记录的字节数,即行记录结构中,delete flag为1的记录大小的总数。

PAGE_LAST_INSERT:最后插入记录的位置。

PAGE_DIRECTION:最后插入的方向。可能的取值为PAGE_LEFT(0x01),PAGE_RIGHT(0x02),PAGE_SAME_REC(0x03),PAGE_SAME_PAGE(0x04),PAGE_NO_DIRECTION(0x05)。

PAGE_N_DIRECTION:一个方向连续插入记录的数量。

PAGE_N_RECS:该页中记录的数量。

PAGE_MAX_TRX_ID:修改当前页的最大事务ID,注意该值仅在Secondary Index定义。

PAGE_LEVEL:当前页在索引树中的位置,0x00代表叶节点。

PAGE_INDEX_ID:当前页属于哪个索引ID。

PAGE_BTR_SEG_LEAF:B+树的叶节点中,文件段的首指针位置。注意该值仅在B+树的Root页中定义。

PAGE_BTR_SEG_TOP:B+树的非叶节点中,文件段的首指针位置。注意该值仅在B+树的Root页中定义。

Infimum和Supremum记录

在InnoDB存储引擎中,每个数据页中有两个虚拟的行记录,用来限定记录的边界。Infimum记录是比该页中任何主键值都要小的值,Supremum指比任何可能大的值还要大的值。这两个值在页创建时被建立,并且在任何情况下不会被删除。在Compact行格式和Redundant行格式下,两者占用的字节数各不相同。下图显示了Infimum和Supremum Records。

User Records与FreeSpace

User Records即实际存储行记录的内容。再次强调,InnoDB存储引擎表总是B+树索引组织的。

Free Space指的就是空闲空间,同样也是个链表数据结构。当一条记录被删除后,该空间会被加入空闲链表中。

Page Directory

Page Directory(页目录)中存放了记录的相对位置(注意,这里存放的是页相对位置,而不是偏移量),有些时候这些记录指针称为Slots(槽)或者目录槽(Directory Slots)。与其他数据库系统不同的是,InnoDB并不是每个记录拥有一个槽,InnoDB存储引擎的槽是一个稀疏目录(sparse directory),即一个槽中可能属于(belong to)多个记录,最少属于4条记录,最多属于8条记录。

Slots中记录按照键顺序存放,这样可以利用二叉查找迅速找到记录的指针。假设我们有(‘i‘,‘d‘,‘c‘,‘b‘,‘e‘,‘g‘,‘l‘,‘h‘,‘f‘,‘j‘,‘k‘,‘a‘),同时假设一个槽中包含4条记录,则Slots中的记录可能是(‘a‘,‘e‘,‘i‘)。

由于InnoDB存储引擎中Slots是稀疏目录,二叉查找的结果只是一个粗略的结果,所以InnoDB必须通过recorder header中的next_record来继续查找相关记录。同时,slots很好地解释了recorder header中的n_owned值的含义,即还有多少记录需要查找,因为这些记录并不包括在slots中。

需要牢记的是,B+树索引本身并不能找到具体的一条记录,B+树索引能找到只是该记录所在的页。数据库把页载入内存,然后通过Page Directory再进行二叉查找。只不过二叉查找的时间复杂度很低,同时内存中的查找很快,因此通常我们忽略了这部分查找所用的时间。

File Trailer

为了保证页能够完整地写入磁盘(如可能发生的写入过程中磁盘损坏、机器宕机等原因),InnoDB存储引擎的页中设置了File Trailer部分。File Trailer只有一个FIL_PAGE_END_LSN部分,占用8个字节。前4个字节代表该页的checksum值,最后4个字节和File Header中的FIL_PAGE_LSN相同。通过这两个值来和File Header中的FIL_PAGE_SPACE_OR_CHKSUM和FIL_PAGE_LSN值进行比较,看是否一致(checksum的比较需要通过InnoDB的checksum函数来进行比较,不是简单的等值比较),以此来保证页的完整性(not corrupted)。

InnoDB数据页结构示例分析

首先我们建立一张表,并导入一定量的数据:

drop table if exists t;

create table t (a int unsigned not null auto_increment,b char(10),primary key(a))ENGINE=InnoDB CHARSET=UTF-8;

delimiter$$

  create procedure load_t(count int unsigned)

    begin

      [email protected]=0;

      [email protected]<count do

        insert into t select null,repeat(char(97+rand()*26),10);

        [email protected][email protected]+1;

      end while;

    end;

$$

delimiter;

call load_t(100);

select * from t limit 10;

接着我们用工具py_innodb_page_info来分析t.ibd,  py_innodb_page_info.py -v t.ibd

看到第四个页(page offset 3)是数据页,通过hexdump来分析t.ibd文件,打开整理得到的十六进制文件,数据页在0x0000c000(16K*3=0xc000)处开始:

先来分析前面File Header的38个字节:

52 1b 24 00数据页的Checksum值。

00 00 00 03页的偏移量,从0开始。

ff ff ff ff前一个页,因为只有当前一个数据页,所以这里为0xffffffff。

ff ff ff ff下一个页,因为只有当前一个数据页,所以这里为0xffffffff。

00 00 00 0a 6a e0 ac 93页的LSN。

45 bf页类型,0x45bf代表数据页。

00 00 00 00 00 00 00这里暂时不管该值。

00 00 00 dc表空间的SPACE ID。

先不急着看下面的Page Header部分,我们来看File Trailer部分。因为File Trailer通过比较File Header部分来保证页写入的完整性。

95 ae 5d 39 Checksum值,该值通过checksum函数和File Header部分的checksum值进行比较。

6a e0 ac 93注意到该值和File Header部分页的LSN后4个值相等。

接着我们来分析56个字节的Page Header部分,对于数据页而言,Page Header部分保存了该页中行记录的大量细节信息。分析后可得:

Page Header(56 bytes):

PAGE_N_DIR_SLOTS=0x001a

PAGE_HEAP_TOP=0x0dc0

PAGE_N_HEAP=0x8066

PAGE_FREE=0x0000

PAGE_GARBAGE=0x0000

PAGE_LAST_INSERT=0x0da5

PAGE_DIRECTION=0x0002

PAGE_N_DIRECTION=0x0063

PAGE_N_RECS=0x0064

PAGE_MAX_TRX_ID=0x0000000000000000

PAGE_LEVEL=00 00

PAGE_INDEX_ID=0x00000000000001ba

PAGE_BTR_SEG_LEAF=0x000000dc0000000200f2

PAGE_BTR_SEG_TOP=0x000000dc000000020032

PAGE_N_DIR_SLOTS=0x001a,代表Page Directory有26个槽,每个槽占用2个字节。

我们可以从0x0000ffc4到0x0000fff7找到如下内容:

0000ffc0 00 00 00 00 00 70 0d 1d 0c 95 0c 0d 0b 85 0a fd|……p……
0000ffd0 0a 75 09 ed 09 65 08 dd 08 55 07 cd 07 45 06 bd|.u……e……U……E..
0000ffe0 06 35 05 ad 05 25 04 9d 04 15 03 8d 03 05 02 7d|.5……%……}
0000fff0 01 f5 01 6d 00 e5 00 63 95 ae 5d 39 6a e0 ac 93|……m……c..]9j……

PAGE_HEAP_TOP=0x0dc0代表空闲空间开始位置的偏移量,即0xc000+0x0dc0=0xcdc0处开始,我们观察这个位置的情况,可以发现这的确是最后一行的结束,接下去的部分都是空闲空间了:

0000cdb0 00 00 00 2d 01 10 70 70 70 70 70 70 70 70 70 70|……-..pppppppppp
0000cdc0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00|……
0000cdd0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00|……
0000cde0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00|……

PAGE_N_HEAP=0x8066,当行记录格式为Compact时,初始值为0x0802,当行格式为Redundant时,初始值是2。其实这些值表示页初始时就已经有Infinimun和Supremum的伪记录行,0x8066-0x8002=0x64,代表该页中实际的记录有100条记录。

PAGE_FREE=0x0000代表删除的记录数,因为这里我们没有进行过删除操作,所以这里的值为0。

PAGE_GARBAGE=0x0000,代表删除的记录字节为0,同样因为我们没有进行过删除操作,所以这里的值依然为0。

PAGE_LAST_INSERT=0x0da5,表示页最后插入的位置的偏移量,即最后的插入位置应该在0xc0000+0x0da5=0xcda5,查看该位置:

0000cda0 00 03 28 f2 cb 00 00 00 64 00 00 00 51 6e 4e 80|..(……d……QnN.
0000cdb0 00 00 00 2d 01 10 70 70 70 70 70 70 70 70 70 70|……-..pppppppppp
0000cdc0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00|……

可以看到,最后这的确是最后插入a列值为100的行记录,但是这次直接指向了行记录的内容,而不是指向行记录的变长字段长度的列表位置。

PAGE_DIRECTION=0x0002,因为我们是通过自增长的方式进行行记录的插入,所以PAGE_DIRECTION的方向是向右。

PAGE_N_DIRECTION=0x0063,表示一个方向连续插入记录的数量,因为我们是以自增长的方式插入了100条记录,因此该值为99。

PAGE_N_RECS=0x0064,表示该页的行记录数为100,注意该值与PAGE_N_HEAP的比较,PAGE_N_HEAP包含两个伪行记录,并且是通过有符号的方式记录的,因此值为0x8066。

PAGE_LEVEL=0x00,代表该页为叶子节点。因为数据量目前较少,因此当前B+树索引只有一层。B+数叶子层总是为0x00。

PAGE_INDEX_ID=0x00000000000001ba,索引ID。

上面就是数据页的Page Header部分了,接下去就是存放的行记录了,前面提到过InnoDB存储引擎有2个伪记录行,用来限定行记录的边界,我们接着往下看:

0000c050 00 02 00 f2 00 00 00 dc 00 00 00 02 00 32 01 00|……2..
0000c060 02 00 1c 69 6e 66 69 6d 75 6d 00 05 00 0b 00 00|……infimum……
0000c070 73 75 70 72 65 6d 75 6d 0a 00 00 00 10 00 22 00|supremum……".

观察0xc05E到0xc077,这里存放的就是这两个伪行记录,InnoDB存储引擎设置伪行只有一个列,且类型是Char(8)。伪行记录的读取方式和一般的行记录并无不同,我们整理后可以得到如下的结果:

#Infimum伪行记录
01 00 02 00 1c/*recorder header*/
69 6e 66 69 6d 75 6d 00/*只有一个列的伪行记录,记录内容就是Infimum(多了一个0x00字节)
*/
#Supremum伪行记录
05 00 0b 00 00/*recorder header*/
73 75 70 72 65 6d 75 6d/*只有一个列的伪行记录,记录内容就是Supremum*/

我们来分析infimum行记录的recorder header部分,最后2个字节位00 1c表示下一个记录的位置的偏移量,即当前行记录内容的位置0xc063+0x001c,得到0xc07f。0xc07f应该很熟悉了,我们前面的分析的行记录结构都是从这个位置开始。我们来看一下:

0000c070 73 75 70 72 65 6d 75 6d 0a 00 00 00 10 00 22 00|supremum……".
0000c080 00 00 01 00 00 00 51 6d eb 80 00 00 00 2d 01 10|……Qm……-..
0000c090 64 64 64 64 64 64 64 64 64 64 0a 00 00 00 18 00|dddddddddd……
0000c0a0 22 00 00 00 02 00 00 00 51 6d ec 80 00 00 00 2d|"……Qm……-
可以看到这就是第一条实际行记录内容的位置了,如果整理后可以得到:
/*第一条行记录*/
00 00 00 01/*因为我们建表时设定了主键,这里ROWID即位列a的值1*/
00 00 00 51 6d eb/*Transaction ID*/
80 00 00 00 2d 01 10/*Roll Pointer*/
64 64 64 64 64 64 64 64 64 64/*b列的值‘aaaaaaaaaa‘*/

这和我们查表得到的数据是一致的:select a,b,hex(b) from t order by a limit 1;

通过recorder header最后2个字节记录的下一行记录的偏移量,我们就可以得到该页中所有的行记录;通过page header的PAGE_PREV,PAGE_NEXT就可以知道上一个页和下个页的位置。这样,我们就能读到整张表所有的行记录数据。

最后我们来分析Page Directory,前面我们已经提到了从0x0000ffc4到0x0000fff7是当前页的Page Directory,如下:

0000ffc0 00 00 00 00 00 70 0d 1d 0c 95 0c 0d 0b 85 0a fd|……p……
0000ffd0 0a 75 09 ed 09 65 08 dd 08 55 07 cd 07 45 06 bd|.u……e……U……E..
0000ffe0 06 35 05 ad 05 25 04 9d 04 15 03 8d 03 05 02 7d|.5……%……}
0000fff0 01 f5 01 6d 00 e5 00 63 95 ae 5d 39 6a e0 ac 93|……m……c..]9j……

需要注意的是,Page Directory是逆序存放的,每个槽2个字节。因此我们可以看到:00 63是最初行的相对位置,即0xc063;0070就是最后一行记录的相对位置,即0xc070。我们发现,这就是前面我们分析的infimum和supremum的伪行记录。Page Directory槽中的数据都是按照主键的顺序存放,因此找具体的行就需要通过部分进行。前面已经提到,InnoDB存储引擎的槽是稀疏的,还需通过recorder header的n_owned进行进一步的判断。如,我们要找主键a为5的记录,通过二叉查找Page Directory的槽,我们找到记录的相对位置在00 e5处,找到行记录的实际位置0xc0e5:

0000c0e0 04 00 28 00 22 00 00 00 04 00 00 00 51 6d ee 80|..(."……Qm..
0000c0f0 00 00 00 2d 01 10 69 69 69 69 69 69 69 69 69 69|……-..iiiiiiiiii
0000c100 0a 00 00 00 30 00 22 00 00 00 05 00 00 00 51 6d|……0."……Qm
0000c110 ef 80 00 00 00 2d 01 10 6e 6e 6e 6e 6e 6e 6e 6e|……-..nnnnnnnn
0000c120 6e 6e 0a 00 00 00 38 00 22 00 00 00 06 00 00 00|nn……8."……
0000c130 51 6d f0 80 00 00 00 2d 01 10 71 71 71 71 71 71|Qm……-..qqqqqq
0000c140 71 71 71 71 0a 00 00 00 40 00 22 00 00 00 07 00|qqqq……@."……

可以看到第一行的记录是4不是我们要找的5,但是我们看前面的5个字节的recordheader,04 00 28 00 22,找到4~8位表示n_owned值的部分,该值为4,表示该记录有4个记录,因此还需要进一步查找。通过recorder和ader最后2个字节的偏移量0x0022,找到下一条记录的位置0xc107,这才是我们要找的主键为5的记录。

时间: 2024-10-04 17:27:58

InnoDB的数据页结构的相关文章

InnoDB数据页结构

定义 InnoDB管理存储空间的基本单位,一个页一般是16kb.InnoDB有多种类型的页用于存储不同信息.我们以记录为单位将数据存储在表中,所以存放记录的页又称数据页.数据页是一个双链表记录记录上下页信息. 数据页结构 file header文件头部(38byte):描述页的基本信息,比如页号,页类型,上页下页信息(促使数据页组成双链表结构). page header页面头部(56byte):存储数据页中存储记录的状态值,比如页目录中槽数量,本页的记录数量等 Infimum + supremu

SQL Server :理解数据页结构

我们都很清楚SQL Server用8KB 的页来存储数据,并且在SQL Server里磁盘 I/O 操作在页级执行.也就是说,SQL Server 读取或写入所有数据页.页有不同的类型,像数据页,GAM,SGAM等.在这文章里,让我们一起来理解下数据页结构. SQL Server把数据记录存在数据页(Data Page)里.数据记录是堆表里.聚集索引里叶子节点的行. 数据页由3个部分组成.页头(标头),数据区(数据行和可用空间)及行偏移数组. 在我们讨论在SQL Server里,数据页内部结构具

INNODB 数据页结构

InnoDB DataPage 16384B 16K 38B FILE HEADER 56B PAGE HEADER RECORD Infimum + supremum Records UserRecords Free Space Page Directory 8B File Trailer FILE HEADER 占用38个字节 名称 大小 FIL_PAGE_SPACE_OR_CHECKSUM 4 保证页的可靠与完整的CHECKSUM校验码 FIL_PAGE_OFFSET 4 表空间中页的偏移

更改Innodb 数据页大小优化MySQL

更改Innodb 数据页大小优化MySQL http://www.mysqlsupport.cn/change_innodb_page_size/ 更改Innodb 数据页大小优化MySQL 2009年12月13日 Posted by wubx 作者:吴炳锡 来源:http://www.mysqlsupport.cn/ 联系方式: wubingxi#gmail.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.         我们知道Innodb的数据页是16K,而且是一个硬性

SQL Server :理解数据记录结构

在SQL Server :理解数据页结构我们提到每条记录都有7 bytes的系统行开销,那这个7 bytes行开销到底是一个什么样的结构,我们一起来看下. 数据记录存储我们具体的数据,换句话说,它存在堆表里,或者存在聚集索引的叶子节点.数据记录结构是为了让SQL Server更高效的管理数据.我们来看下数据记录结构示意图: 上图中蓝色部分是所有数据记录部分,绿色部分是表结构里取决于定长/变长列的数据记录部分. 行头系统数据: 用做状态位1的第1字节(8位)是用来定义记录的属性: 第0位:版本信息

翻译(数据页和数据行)

专业SQL服务器内部 了解在引擎盖下发生了什么,以及它是如何影响你的 第二版 数据页和数据行 数据库中的空间被划分为逻辑8KB页面.这些页面从0开始连续编号,可以通过指定文件ID和页码来引用它们.页面编号总是连续的,这样当SQL Server增长数据库文件时,新页面的编号将从文件中最高的页码加1开始.类似地,当SQL Server压缩文件时,它会从文件中删除数量最多的页面. 数据存储在SQL SERVER中 一般来说,SQL Server存储和处理数据库中的数据有三种不同的方式或技术.使用传统的

mysql之innodb存储引擎---数据存储结构

一.背景 1.1文件组织架构 首先看一下mysql数据系统涉及到的文件组织架构,如下图所示: msyql文件组织架构图 从图看出: 1.日志文件:slow.log(慢日志),error.log(错误日志),general.log(基本日志) 2.配置文件:my.cnf 3.数据库:performance_schema,mysql,information_schema,sys 4.innodb存储引擎(框中部分),主要包括有:两个日志文件ib_logfile0和ib_logfile1,由参数inn

探究InnoDB数据页内部行的存储方式

*:first-child { margin-top: 0 !important; } .markdown-body>*:last-child { margin-bottom: 0 !important; } .markdown-body .anchor { position: absolute; top: 0; bottom: 0; left: 0; display: block; padding-right: 6px; padding-left: 30px; margin-left: -30

利用innodb_force_recovery修复MySQL数据页损坏

现象:启动MySQL服务时报1067错误,服务无法启动. 查看xxx.err错误日志发现有数据页损坏信息: InnoDB: Database page corruption on disk or a failed InnoDB: file read of page 200. 出现上述现象是由于突然断电.强制关机.强制杀死MySQL进程等操作所导致的. 首先修改my.ini中的innodb_force_recovery参数(4-6),使mysqld跳过恢复步骤,将mysqld 启动,将数据导出来然