MySQL Internal - InnoDB存储引擎(行结构)

InnoDB行存储的三个组成部分(说明: F字符表示列的数量)

名称(Name) 大小(Size)
Field Start Offsets (F*1) or (F*2) bytes
Extra Bytes 6 bytes
Field Contents 取决于内容

1: FIELD START OFFSETS

指在实际数据存储行中每一字段(entry,实际存储不只是包括列,还有额外信息)的位置偏移量信息列表,这个位置由原点(Origin)相对位置和下一个字段计算而来。该列表保存的行中每一字段的偏移信息为倒序的,也就是说行中第一字段信息在这个列表的最后。

举个例子:假设有三个列,第一个列的长度为1字节,第二个为2字节,第三个为4字节,这种情况下,保存三个列的偏移信息分别为[1,3(1+2),7(1+2+4)],列表倒序,转储的Field Start Offsets的信息应该为[07,03,01].

有两种的特殊复杂情况:

1:偏移量数字可能为一个或两个字节,一个字节最多允许长度为127,最高位bit用来保存是否为NULL,"Extra Bytes"部分说明了偏移量为一个字节还是两个字节。

2:偏移量可能有一个标志信息,剩下的字节空间包含两个段,指具体的内容。(可能这些内容并不在同一个页中,参考后面的分析)

当偏移量为一个字节时:

1 bit = NULL

7 bit, 实际的偏移信息

当偏移量为两个字节时:

1 bit = NULL

1 bit = 0 内容在同一个页中,= 1 内容在不同的页中

14 bits = 实际的偏移量,0 ~ 16383

2:EXTRA BYTES

Extra Bytes为6个字节

Name Size Description
info_bits: ?? ??
() 1 bit 未使用
() 1 bit 未使用
deleted_flag 1 bit 1:删除标志位(已删除)
min_rec_flag 1 bit 1: 预定义的最小记录
n_owned 4 bits 拥有的记录数量
heap_no 13 bits 堆块中索引的数据页序列编号
n_fields 10 bits 记录中的字段数量 1 to 1023
1byte_offs_flag 1 bit 1:Field Start Offsets为一个字节,否则为两个字节
next 16 bits 16 bits 下一个记录的指针(System Column #1)
TOTAL 48 bits ??

共48 bit,6个字节

如果需要通过字节读取这存储的记录,最关键的需要读取Extra Bytes 中的byte_offs_flag位信息,需要知道1表示偏移信息为一个字节,0表示两个字节

如果给定了一个相对原点(Origin),InnoDB获取记录开始遵循如下步骤:

-- X = n_fields,这个数字等于Field Start Offsets列表中的定义的数量

-- 如果byte_offs_flag = 0,X = X * 2,每个偏移量为两个字节表示的

-- X = X + 6,固定大小的Extra Bytes为6字节

-- 记录的开始位置当前的位置减去X

(参照FIELD CONTENTS)

3:FIELD CONTENTS

Field Contents部分包括了记录的所有数据,这些字段按照我们预定义的方式按顺序存储。

字段与字段没有任何标记,记录的结尾也没有任何标志。

实例:

-- 创建一张表

CREATE TABLE T
    (FIELD1 VARCHAR(3), FIELD2 VARCHAR(3), FIELD3 VARCHAR(3))
    Type=InnoDB;

需要知道的是,InnoDB下表中的每一行有6个字段,并不是3个,因为InnoDB在存储的内容前自动补充的3个列("system columns"),这些列分别为 行ID(row ID,该表未定义主键),事务ID(transaction ID), 回滚指针(rollback pointer)。

-- 为该表增加三条数据

INSERT INTO T VALUES (‘PP‘, ‘PP‘, ‘PP‘);
INSERT INTO T VALUES (‘Q‘, ‘Q‘, ‘Q‘);
INSERT INTO T VALUES (‘R‘, NULL, NULL);

运行工具(Borland‘s TDUMP)查看二进制的事务文件信息(\mysql\data\ibdata1


Address Values in Hexadecimal


Values in ASCII


0D4280: 00 00 2D 00 84 4F 4F 4F 4F 4F 4F 4F 4F 4F 19 17


..-..OOOOOOOOO..


0D4290: 15 13 0C 06 00 00 78 0D 02 BF 00 00 00 00 04 21


......x........!


0D42A0: 00 00 00 00 09 2A 80 00 00 00 2D 00 84 50 50 50


.....*....-..PPP


0D42B0: 50 50 50 16 15 14 13 0C 06 00 00 80 0D 02 E1 00


PPP.............


0D42C0: 00 00 00 04 22 00 00 00 00 09 2B 80 00 00 00 2D


....".....+....-


0D42D0: 00 84 51 51 51 94 94 14 13 0C 06 00 00 88 0D 00


..QQQ...........


0D42E0: 74 00 00 00 00 04 23 00 00 00 00 09 2C 80 00 00


t.....#.....,...


0D42F0: 00 2D 00 84 52 00 00 00 00 00 00 00 00 00 00 00


.-..R...........

做一下格式处理,添加标记:

19 17 15 13 0C 06 Field Start Offsets /* First Row */
00 00 78 0D 02 BF Extra Bytes
00 00 00 00 04 21 System Column #1
00 00 00 00 09 2A System Column #2
80 00 00 00 2D 00 84 System Column #3
50 50 Field1 ‘PP‘
50 50 Field2 ‘PP‘
50 50 Field3 ‘PP‘

16 15 14 13 0C 06 Field Start Offsets /* Second Row */
00 00 80 0D 02 E1 Extra Bytes
00 00 00 00 04 22 System Column #1
00 00 00 00 09 2B System Column #2
80 00 00 00 2D 00 84 System Column #3
51 Field1 ‘Q‘
51 Field2 ‘Q‘
51 Field3 ‘Q‘

94 94 14 13 0C 06 Field Start Offsets /* Third Row */
00 00 88 0D 00 74 Extra Bytes
00 00 00 00 04 23 System Column #1
00 00 00 00 09 2C System Column #2
80 00 00 00 2D 00 84 System Column #3
52 Field1 ‘R‘

-- "Field Start Offsets"

参照First Row,从Extra Bytes开始的7个字段,大小分别为6, 6, 7, 2, 2, 2,偏移信息指向了下一字段的开始位置,16进制表示下的数字06, 0c (6+6), 13 (6+6+7), 15 (6+6+7+2), 17 (6+6+7+2+2), 19 (6+6+7+2+2+2),倒序的Field Start Offsets值分别为:[19,17,15,13,0c,06]

-- "Extra Bytes"

参照First Row,Extra Bytes为[00 00 78 0D 02 BF],参照EXTRA BYTES读取跳过头21 bit读(n_fields),取10个bit,读取第三个字节最后三个个bit [000]和第四个字节0D[00001101]的7个bit [0000110],得出的6即为字段的数量(除去Extra Bytes),第四个字节0D[00001101]最后bit:1表示byte_offs_flag说明偏移量为1字节,最后的第5,6字节02 BF,指向下一行Second Row(System Column #1)的记录(02BF为0D42BF页内地址),下一记录指向了System Column #1,读取过程遵循EXTRA BYTES末的规则。

-- NULL列的表示

参照Third Row,FIELD2和FIELD3为NULL,因为byte_offs_flag为1,因此,在Field Start Offsets中[94 94 14 13 0C 06]每次读取1个字节可表示字段的偏移信息,这个字节最高位为NULL标记,14 13表示1个字节[52]的FIELD1值‘R‘,94 14表示0字节的FIELD2值NULL(94最高位为1表示NULL,其余7 bit为14),94 94表示0字节的FIELD3值NULL。

时间: 2024-10-10 14:40:48

MySQL Internal - InnoDB存储引擎(行结构)的相关文章

mysql中InnoDB存储引擎的行锁和表锁

Mysql的InnoDB存储引擎支持事务,默认是行锁.因为这个特性,所以数据库支持高并发,但是如果InnoDB更新数据的时候不是行锁,而是表锁的话,那么其并发性会大打折扣,而且也可能导致你的程序出错. 而导致行锁变为表锁的情况之一就是: SQL的更新(update)或者删除(delete)语句中未使用到索引,导致在InnoDB在对数据进行相应操作的时候必须把整个表锁起来进行检索(表锁).而如果使用了索引的话,InnoDB只会通过索引条件检索数据,而只锁住索引对应的行(行锁). 下面记录一下我遇到

MySQL数据库InnoDB存储引擎多版本控制(MVCC)实现原理分析

文/何登成 导读:   来自网易研究院的MySQL内核技术研究人何登成,把MySQL数据库InnoDB存储引擎的多版本控制(简称:MVCC)实现原理,做了深入的研究与详细的文字图表分析,方便大家理解InnoDB存储引擎实现的多版本控制技术(简称:MVCC). 基本知识 假设对于多版本控制(MVCC)的基础知识,有所了解.MySQL数据库InnoDB存储引擎为了实现多版本的一致性读,采用的是基于回滚段的协议. 行结构 MySQL数据库InnoDB存储引擎表数据的组织方式为主键聚簇索引.由于采用索引

MySQL数据库InnoDB存储引擎中的锁机制

MySQL数据库InnoDB存储引擎中的锁机制    http://www.uml.org.cn/sjjm/201205302.asp   00 – 基本概念 当并发事务同时访问一个资源的时候,有可能导致数据不一致.因此需要一种致机制来将访问顺序化. 锁就是其中的一种机制.我们用商场的试衣间来做一个比喻.试衣间供许多消费者使用.因此可能有多个消费者同时要试衣服.为了避免冲突,试衣间的门上装了锁.试衣服的人在里边锁住,其他人就不能从外边打开了.只有里边的人开门出来,外边的人才能进去. - 锁的基本

细聊MySQL的Innodb存储引擎(完)

细聊MySQL的Innodb存储引擎(一) 细聊MySQL的Innodb存储引擎(二) 细聊MySQL的Innodb存储引擎(完) 上篇主要和大家探讨了Innodb引擎中出现幻读的处理方法与死锁的探测及避免死锁的一些注意事项.此篇,我们来研究下Innodb的索引. Innodb里涉及到的索引主要有四种,分别为聚簇索引(Clustered Index).次级索引(Secondary Index).全文索引(FULLTEXT Index).哈希索引(Hash Index). 聚簇索引与次级索引 每一

细聊MySQL的Innodb存储引擎(二)

细聊MySQL的Innodb存储引擎(一) 上一篇主要和大家探讨了下Innodb的锁机制与隔离机制.本篇来和大家一起研究下在使用Innodb是会出现的问题以及如何解决它们. Innodb是如何解决幻读问题的 什么是幻读?听起来似乎很高端,但实际上它只是反映了事务中的一种数据不一致的情况.下面看我来描述这样一个场景,通过这个场景,大家就能很清楚的知道幻读到底是什么意思. 打开两个客户端,设为A和B A客户端 mysql> start transaction; (步骤一) Query OK, 0 r

MySQL数据库InnoDB存储引擎

MySQL数据库InnoDB存储引擎Log漫游  http://blog.163.com/zihuan_xuan/blog/static/1287942432012366293667/ MySQL数据库InnoDB存储引擎,布布扣,bubuko.com

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

MySQL:InnoDB存储引擎的B+树索引算法

很早之前,就从学校的图书馆借了MySQL技术内幕,InnoDB存储引擎这本书,但一直草草阅读,做的笔记也有些凌乱,趁着现在大四了,课程稍微少了一点,整理一下笔记,按照专题写一些,加深一下印象,不枉读了一遍书.与此同时,也加深一下对MySQL的了解,认识了原理,对优化的原则才有把握,对问题的分析才有源头. 关于B+树数据结构 ①InnoDB存储引擎支持两种常见的索引. 一种是B+树,一种是哈希.B+树中的B代表的意思不是二叉(binary),而是平衡(balance),因为B+树最早是从平衡二叉树

MySQL 温故而知新--Innodb存储引擎中的锁

近期碰到非常多锁问题.所以攻克了后,细致再去阅读了关于锁的书籍,整理例如以下:1,锁的种类 Innodb存储引擎实现了例如以下2种标准的行级锁: ? 共享锁(S lock),同意事务读取一行数据. ?  排它锁(X lock).同意事务删除或者更新一行数据. 当一个事务获取了行r的共享锁.那么另外一个事务也能够马上获取行r的共享锁,由于读取并未改变行r的数据.这样的情况就是锁兼容. 可是假设有事务想获得行r的排它锁,则它必须等待事务释放行r上的共享锁-这样的情况就是锁不兼容.二者兼容性例如以下表