- 浏览: 209334 次
- 性别:
- 来自: 杭州
文章分类
最新评论
-
Prepared:
Hadoop的几个明显缺点 -
CSunDNan:
...
openjdk jvm 方法字节码执行过程 -
幻影之蚀:
...
mysql 源码分析2 源码调试环境建立 -
shukongchengje:
紧急呼唤楼主,mysql代码从哪里弄?官网wiki上看的一头雾 ...
mysql源码分析 整体架构 -
yeshaoting:
好文章.不介意的话转载了.
jvm 字节码中文含义
InnoDB记录由三个部分组成,见表1:
表1:InnoDB的记录组织形式
名称 长度
Field Start Offsets F*1或者 (F*2)个字节
Extra Bytes 6个字节
Field Contents 和记录的实际内容相关
备注:
1) “F”是指记录的字段数量。
2) “Field Start Offsets”是一个目录列表,分别指向下一个字段实际存储的偏移值。
3) “Extra Bytes”的长度是不变的,占用6个字节。
4) “Field Contents”存放实际的数据。
记录的起点实际上是从“Field Contents”的第一个字节开始的,而不是从“Field Start Offsets”的第一个字节开始。如果得到一个记录的指针,实际是指向实际记录的起点。因此,如果要得到其它两个部分,只要对指针进行减法操作就行了。比如减去6就得到“Extra Bytes”的起始地址。只有第三部分,是采用对指针的加法操作来得到相应的字段地址偏移。
1 FIELD START OFFSETS(字段偏移量列表)
这是一个目录列表,每一个目录是一个相对于记录起点的偏移量。这些目录是反向存储的,也就是说第一个字段的偏移量是存储在该列表的最后一个目录。
举个例子:假设现在有三个列。第一个列的长度是1,第二个列的长度是2,第三个列的长度是4。在这种情况下,相应的偏移量分别是:1、3(1+2)、7(1+2+4)。但是因为目录列表是反向存储的,所以存储的内容为:07、03、01。
这里面有两种特殊的情况需要考虑:
1) 每个目录的长度或者为1个字节或者为2个字节。只有当记录的总长度小于127时,才可以设置目录长度为1个字节。在“Extra Bytes”中会指出目录的长度是一个字节还是两个字节。
2) 偏移值的最高位通常是标志位。
当每个偏移量是一个字节时:
1) 1 bit=0:字段是非NULL,=1:字段是NULL。
2) 7 bits:实际的偏移值,范围是0到127。
当每个偏移量是两个字节时:
1) 1 bit=0:字段是非NULL,=1:字段是NULL。
2) 1 bit=0:字段存储在同一页,=1:字段存储在不同的页,只有当记录包含大字段对象时才可能出现这一情况。。
3) 14 bits:实际的偏移值,范围是0到16383。
2 EXTRA BYTES(额外字节)
额外字节是定长的,占用6个字节。见表2。
表2:extra bytes的组织形式
名称 长度 描述
info_bits
() 1 bit 没有使用
() 1 bit 没有使用
delete_flag 1 bit 当记录已被删除,设置该标志位为1。
min_rec_flag 1 bit 如果是最小虚拟记录,设置该标志位为1。
n_owned 4 bits 该记录拥有的记录数量
heap_no 13 bits 在索引页的堆中的序号
n_fiels 10 bits 该记录拥有的字段数量,范围为1到1023。
1bytes_offs_flag 1 bit 如果“Files Start Offsets”是1字节的,则设为1。
next 16 bits 16 bits 指向该页的下一条记录
total 48 bits
如果你仅仅打算读取该记录,那么标志位“1byte_offs_flag”必须得读的,因为你需要知道目录指针是1字节的还是2字节的。
当给定记录的起点指针(即指向“Field Contents”),得到目录列表头指针(即指向“Field Start Offsets”)的步骤如下:
1) 令X=n_fields(该数值和目录列表的数量相等)
2) 如果1byte_offs_flag等于0,就是说每个偏移量需要2个字节表示,那么X=X+2。
3) 设X=X+6,因为“Extra Bytes”为6个字节。
4) 所以目录列表头指针的地址,等于记录的起始指针减去X。
3 FIELD CONTENTS(字段内容)
这个部分用来存放记录的实际数据,按照定义的顺序进行存放。
4 举例
创建一张表:
create table t(field1 varchar(3),field2 varchar(3),field3 varchar(3));
尽管在定义中我们只提供了三个列(字段),但实际记录中包含六个列,因为系统自动增加了三个系统列用于管理。三个系统列分别为:ROWID、事务ID、会滚段指针。在这个例子中,我们不考虑这三个列。
插入三条数据:
insert into t values('PP','PP', 'PP');
insert into t values('QQ','QQ', 'QQ');
insert into t values('R',NULL, NULL);
通过dump工作可以得到以下的实际存储数据,见表3:
表3 物理存储中记录的组织形式
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 80 System Column #2
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'
现在我们对记录进行分析:
1)对于第一条记录的六个字段,长度分别为:6、6、6、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)。因为目录列表是反序的,所以存储的值是:19、17、13、0c、06。
2)我们再看第一条记录的“Extra Bytes”部分:00 00 78 0D 02 BF。第四个字节的0D表示二进制是1101,110是n_filed的最后三个bits(继续往前面分析,n_files对应的二进制为0000000110,也就是6,说明该记录由6个字段组成),1101的最后一个1指出了1byte_offs_flag值为1,即每个偏移量占用1个字节。第五个字节和第六个字节组成了02 BF,这是下一个(第二条)记录起点对应的偏移量(相对于页开始处)。
3)现在我们来看第三条记录,“Field Start Offsets”中的94、94,对应着字段field2以及field3。94对应的二进制为1001 0100,最高位的1表示该字段为NULL,字节01 0100指的是下一个字段的偏移值:14。同时,我们可以看到,NULL值并没有真正占用“Field contents”的空间。
表1:InnoDB的记录组织形式
名称 长度
Field Start Offsets F*1或者 (F*2)个字节
Extra Bytes 6个字节
Field Contents 和记录的实际内容相关
备注:
1) “F”是指记录的字段数量。
2) “Field Start Offsets”是一个目录列表,分别指向下一个字段实际存储的偏移值。
3) “Extra Bytes”的长度是不变的,占用6个字节。
4) “Field Contents”存放实际的数据。
记录的起点实际上是从“Field Contents”的第一个字节开始的,而不是从“Field Start Offsets”的第一个字节开始。如果得到一个记录的指针,实际是指向实际记录的起点。因此,如果要得到其它两个部分,只要对指针进行减法操作就行了。比如减去6就得到“Extra Bytes”的起始地址。只有第三部分,是采用对指针的加法操作来得到相应的字段地址偏移。
1 FIELD START OFFSETS(字段偏移量列表)
这是一个目录列表,每一个目录是一个相对于记录起点的偏移量。这些目录是反向存储的,也就是说第一个字段的偏移量是存储在该列表的最后一个目录。
举个例子:假设现在有三个列。第一个列的长度是1,第二个列的长度是2,第三个列的长度是4。在这种情况下,相应的偏移量分别是:1、3(1+2)、7(1+2+4)。但是因为目录列表是反向存储的,所以存储的内容为:07、03、01。
这里面有两种特殊的情况需要考虑:
1) 每个目录的长度或者为1个字节或者为2个字节。只有当记录的总长度小于127时,才可以设置目录长度为1个字节。在“Extra Bytes”中会指出目录的长度是一个字节还是两个字节。
2) 偏移值的最高位通常是标志位。
当每个偏移量是一个字节时:
1) 1 bit=0:字段是非NULL,=1:字段是NULL。
2) 7 bits:实际的偏移值,范围是0到127。
当每个偏移量是两个字节时:
1) 1 bit=0:字段是非NULL,=1:字段是NULL。
2) 1 bit=0:字段存储在同一页,=1:字段存储在不同的页,只有当记录包含大字段对象时才可能出现这一情况。。
3) 14 bits:实际的偏移值,范围是0到16383。
2 EXTRA BYTES(额外字节)
额外字节是定长的,占用6个字节。见表2。
表2:extra bytes的组织形式
名称 长度 描述
info_bits
() 1 bit 没有使用
() 1 bit 没有使用
delete_flag 1 bit 当记录已被删除,设置该标志位为1。
min_rec_flag 1 bit 如果是最小虚拟记录,设置该标志位为1。
n_owned 4 bits 该记录拥有的记录数量
heap_no 13 bits 在索引页的堆中的序号
n_fiels 10 bits 该记录拥有的字段数量,范围为1到1023。
1bytes_offs_flag 1 bit 如果“Files Start Offsets”是1字节的,则设为1。
next 16 bits 16 bits 指向该页的下一条记录
total 48 bits
如果你仅仅打算读取该记录,那么标志位“1byte_offs_flag”必须得读的,因为你需要知道目录指针是1字节的还是2字节的。
当给定记录的起点指针(即指向“Field Contents”),得到目录列表头指针(即指向“Field Start Offsets”)的步骤如下:
1) 令X=n_fields(该数值和目录列表的数量相等)
2) 如果1byte_offs_flag等于0,就是说每个偏移量需要2个字节表示,那么X=X+2。
3) 设X=X+6,因为“Extra Bytes”为6个字节。
4) 所以目录列表头指针的地址,等于记录的起始指针减去X。
3 FIELD CONTENTS(字段内容)
这个部分用来存放记录的实际数据,按照定义的顺序进行存放。
4 举例
创建一张表:
create table t(field1 varchar(3),field2 varchar(3),field3 varchar(3));
尽管在定义中我们只提供了三个列(字段),但实际记录中包含六个列,因为系统自动增加了三个系统列用于管理。三个系统列分别为:ROWID、事务ID、会滚段指针。在这个例子中,我们不考虑这三个列。
插入三条数据:
insert into t values('PP','PP', 'PP');
insert into t values('QQ','QQ', 'QQ');
insert into t values('R',NULL, NULL);
通过dump工作可以得到以下的实际存储数据,见表3:
表3 物理存储中记录的组织形式
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 80 System Column #2
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'
现在我们对记录进行分析:
1)对于第一条记录的六个字段,长度分别为:6、6、6、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)。因为目录列表是反序的,所以存储的值是:19、17、13、0c、06。
2)我们再看第一条记录的“Extra Bytes”部分:00 00 78 0D 02 BF。第四个字节的0D表示二进制是1101,110是n_filed的最后三个bits(继续往前面分析,n_files对应的二进制为0000000110,也就是6,说明该记录由6个字段组成),1101的最后一个1指出了1byte_offs_flag值为1,即每个偏移量占用1个字节。第五个字节和第六个字节组成了02 BF,这是下一个(第二条)记录起点对应的偏移量(相对于页开始处)。
3)现在我们来看第三条记录,“Field Start Offsets”中的94、94,对应着字段field2以及field3。94对应的二进制为1001 0100,最高位的1表示该字段为NULL,字节01 0100指的是下一个字段的偏移值:14。同时,我们可以看到,NULL值并没有真正占用“Field contents”的空间。
发表评论
-
mysql 核心内幕
2010-03-30 17:34 1366目录 第1章 MySQL的前世今生 1.1 MySQ ... -
并发控制原理
2010-03-30 17:31 995事务之间的相互影响可能导致数据库状态的不一致,即使各个事务能保 ... -
聚集索引与非聚集索引的基本概念
2010-03-30 17:14 1310聚集索引,是一种指明 ... -
bitmap索引的深入研究
2010-03-30 17:03 1385位图(bitmap)索引是另外一种索引类型,它的组织形式与B树 ... -
Mysql源代码分析系列
2010-03-30 16:51 5874Mysql源代码分析系列(2): 源代码结构 Mysql ... -
并发控制原理
2010-03-30 16:46 939事务之间的相互影响可能导致数据库状态的不一致,即使各个事务能保 ... -
数据库性能调优技术
2010-03-30 16:45 749一、概述 随着数据库在各个领域的使用不断增长,越来越多 ... -
日志系统原理
2010-03-30 16:40 1002一:事务系统 1.事务的工作模型 事务必须满足原子性,所 ... -
mysql内核分析--innodb哈希表的内部实现(上)
2010-03-30 16:36 13191.哈希表的概述 hash表的实现是innodb的基 ... -
Mysql查询优化器浅析
2010-03-30 16:33 9891 定义 Mysql查询优化器的工作是为查询语句选择 ... -
InnoDB页结构浅析
2010-03-30 16:32 1184InnoDB将所有的记录存放在数据库页中(也可以称为数据块)。 ... -
mysql5.1在windows下的编译方法
2010-03-30 16:28 1297编译步骤 1、从mysql.com ... -
mysql 在 VS2005上面单步调试
2010-03-30 13:39 1523mysql 在 VS2005上面单步调试 收藏 http:/ ... -
mysql 源码分析2 源码调试环境建立
2010-03-05 12:57 13761.下载源码 2.建立工程 3.调试 待续。。。 -
memcached 架构分析
2009-12-13 21:08 1110memcached 架构分析 -
无法抗衡关系型数据库 NoSQL革命仍要等待
2009-08-04 02:40 1139NoSQL架构可以省去将Web或者Java 应用和数据转换成S ... -
no sql
2009-08-04 02:31 925什么是NoSQL 1.不要叫它们数据库。 2.它们可以处理超大 ... -
B树
2009-07-28 16:35 1065B树 即二叉搜索树: 1.所有 ... -
索引基础
2009-07-28 14:43 9171.索引是什么? 索引是一个单独的、物理的数据库结构, ... -
mysql源码分析 整体架构
2009-07-28 03:13 8625大致分析完了mysql整体架构 明确了mysql架构,其实也就 ...
相关推荐
在探讨InnoDB记录结构之前,我们首先需要了解MySQL数据库的基本运行机制,尤其是其存储引擎的概念。在MySQL中,存储引擎负责对表中数据的读取和写入工作,不同的存储引擎设计用于提供不同的特性,它们所使用存储数据...
### Innodb存储引擎浅析—事务系统 #### 学述 在MySQL的众多存储引擎中,InnoDB无疑是最为重要且被广泛使用的之一。本文旨在深入解析InnoDB存储引擎中的事务处理机制及其背后的设计原理。 #### 存储引擎介绍 在...
《InnoDB记录存储结构解析》 在MySQL的世界里,存储引擎是数据库管理的核心组件,它负责数据的存储和检索。其中,InnoDB是最常见的存储引擎,以其事务安全性和高性能著称。本文将深入探讨InnoDB的记录存储结构,...
### MySQL核心Innodb存储引擎浅析—事务系统 #### 存储引擎介绍 在MySQL中,存储引擎是处理表的存储方式的核心组件之一。不同的存储引擎提供了不同的特性,如事务支持、锁定粒度等。其中,MyISAM和InnoDB是最常用...
【InnoDB索引结构浅析】 InnoDB是MySQL数据库中常用的一种存储引擎,以其支持事务处理和行级锁定而著名。在InnoDB中,索引的构建和组织方式对数据库性能有着重大影响。本文将深入探讨InnoDB的索引特性,特别是聚集...
标题《XtraDB、InnoDB 内部结构示意图》表明文章将重点介绍MySQL数据库中XtraDB和InnoDB存储引擎的内部架构。由于内容描述中未给出更详细的信息,我们将基于提供的部分内容来推测文章的核心知识点。 从内容来看,...
### MySQL体系结构及原理(innodb)图文完美解析 #### 宏观认识 在深入探讨MySQL的体系结构及其核心组件InnoDB之前,我们先来理解几个基础概念。 1. **MySQL简介** MySQL是一种开源的关系型数据库管理系统(RDBMS)...
在深入探讨MySQL Innodb索引之前,我们先了解几种基本的树形数据结构,包括二叉搜索树、B树、B+树以及B*树。 ##### 1.1 搜索二叉树(Binary Search Tree) 搜索二叉树是一种特殊的二叉树,每个节点至多有两个子...
1.3.0.InnoDB磁盘结构——逻辑存储结构.md 1.3.1.InnoDB磁盘结构——表.md 1.3.2.InnoDB磁盘结构——索引.md 1.3.3.InnoDB磁盘结构——表空间.md 1.4.0.Mysql文件——参数文件.md 1.4.1.0.Mysql文件——日志文件.md ...
例如,当我们对记录进行插入、删除或更新操作时,InnoDB会根据记录头信息在用户记录区域中寻找合适的位置,或者更新链表结构以反映当前的记录状态。 通过上述内容,我们对InnoDB数据页结构有了初步的了解。但要完全...
前言mysql中有很多的引擎,不同的引擎存储数据的方式是不同的,本文以InnoDB为例进行讲解InnoDB页简介为了提高效率,InnoDB以页作为磁盘和内存之间
2.1 InnoDB体系结构 2.2 Checkpoint技术 2.3 Master Thread工作方式 2.4 InnoDB关键特性 3. 文件 3.1 参数文件 3.2 日志文件 3.3 套接字文件 3.4 pid文件 3.5 表结构定义文件 3.6 InnoDB存储引擎文件 4. ...
标题《Innodb和XtraDB结构和性能优化》涉及的是数据库技术领域,特别是关于MySQL数据库中的存储引擎Innodb与XtraDB的内部结构和性能调优方法。Innodb是MySQL最流行的存储引擎之一,以支持事务处理和行级锁定著称。...
总结,学习MySQL的原理,特别是InnoDB的底层结构、锁机制、事务管理和并发控制,对于提升数据库性能和保证数据安全性至关重要。通过深入理解这些核心概念,开发者能够更好地设计和优化数据库,满足高性能、高可用性...
为了高效管理User Records中的记录,InnoDB采用了一种叫做B+树的数据结构,使得数据的查找、插入和删除操作具有良好的性能。行格式的不同会影响记录的存储方式,例如,COMPACT格式会更紧凑地存储数据,减少空间浪费...
以上总结了InnoDB日志结构的基本知识点,旨在帮助IT专业人员深入理解InnoDB日志的工作原理和配置管理方法。实际应用中,对于日志文件的管理需要结合具体的业务场景和性能要求,制定出合理的策略和最佳实践。
【InnoDB 索引结构详解】 InnoDB和MyISAM是MySQL中两种常见的存储引擎,它们在事务处理、锁粒度以及并发性方面存在显著差异。InnoDB支持事务处理,提供行级锁,适合高并发环境。而MyISAM不支持事务,采用表级锁,...
通过这个工具,我们可以查看InnoDB的页类型、页头信息、记录、B树结构等关键元素,这对于理解数据的存储和检索过程至关重要。 InnoDB存储引擎中的日志系统是其核心特性之一。redo log(重做日志)是保证事务持久性...
Page结构是InnoDB存储和检索数据的核心,它不仅包含实际的数据记录,还包含了许多用于管理的元数据。 1. **Page Header**:Page头部包含了关于Page的一些基本信息,如Page类型(例如,数据页、索引页等)、Page的...