INNODB SYSTEM RECORD infimum和supremum的举例分析

52次阅读

共计 7295 个字符，预计需要花费 19 分钟才能阅读完成。

这篇文章主要介绍“INNODB SYSTEM RECORD infimum 和 supremum 的举例分析”，在日常操作中，相信很多人在 INNODB SYSTEM RECORD infimum 和 supremum 的举例分析问题上存在疑惑，丸趣 TV 小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”INNODB SYSTEM RECORD infimum 和 supremum 的举例分析”的疑惑有所帮助！接下来，请跟着丸趣 TV 小编一起来学习吧！

我们知道在一个 C 语言中最后一个链表的 NEXT 指针指向的 NULL 空指针，那么这里 SUPREMUM 实际就是 NULL 空指针及 0
他们位置固定在块的 94-120 字节，其中 94-107 为 infimum 相关信息，而 107 到 120 为 supremum 相关信息

info flags 4bits
number of records owned 4bits
order 13bits
record type 3bits
next record offset 2bytes
infimum\0 8bytes (C 语言数组以 \0 表示结尾)
以上是 infimum 固定信息
info flags 4bits
number of records owned 4bits
order 13bits
record type 3bits
next record offset 2bytes
supremum 8bytes
以上是 supremum 固定信息

我们同样适用 bcview 来查看 infimum 信息，当然查看的还是块 3(0 开头实际是第 4 个块)
bcview km1.ibd 16 94 16|more

current block:00000003–Offset:00094–cnt bytes:13–data is:0100020041696e66696d756d00
1、info flags
这 4 位 (4bits) 标示是一个行标识，其中 binary 0001 表示最小的行，其中 binary 0010 表示是删除的行，而 infimum 和 supremum 行在我测试数据库中为 binary 0000
2、number of records owned
这 4 位 (4bits) 表示在本 page directory(槽)中的记录数，关于槽的概念后面详细探讨
3、order
这 13 位 (13bits) 表示记录插入到块中顺序，INFIMUM 恒等于 0 而 SPREMUM 恒等于 1，而数据行的 ORDER 从 2 开始
4、record type
这 3 位 (3bits) 表示记录的类型，supermum 恒等于 3 及 binary 011,infimum 恒等于 2 及 binary010，节点指针为 1 及 001，数据行为 000
5、next record offset
这 2 个字节在 INFIMUM 中表示的是第一个行的偏移量这个偏移量是当前记录的位置 +offset，这个 offset 直接指向了数据而相关的行头在 offset- n 开始 n 为行头的开销。
当然 supermum 为的偏移量就是 NULL 空指针了。
6、infimum\0 OR supremum
这没什么好解释的就是实际的 ASCII 值
我们还是适用我写工具 mysqlblock 和 bcview 进行验证

[root@hadoop1 test]# mysqlblock km1.ibd -d
***************************************************
USEAGE: mysqlblock datafile -t/-d
This small tool used in study and test database,not
uesd on online database!
This tool is used to find how many blocks and types
in specified datafile,Exp:how many undo block in d
ata file!
QQ:2238980
***************************************************
-t Only Total blocks types in ibdata!
-d Blocks types detail in ibdata!
***************************************************
FILE SIZE IS : 98304
current read blocks is : 0 –This Block is file space header blocks!
current read blocks is : 1 –This Block is insert buffer bitmap blocks!
current read blocks is : 2 –This Block is inode blocks!
current read blocks is : 3 –This Block is data blocks(index pages)!
current read blocks is : 4 –This Block is new allocate blocks!
current read blocks is : 5 –This Block is new allocate blocks!
Total Block Status :
Total block : 6,Total size is: 0.093750 MB
Total undo block : 0,Total size is: 0.000000 MB
Total inode block : 1,Total size is: 0.015625 MB
Total insert buffer free blocks: 0,Total size is: 0.000000 MB
Total data(index pages) block : 1,Total size is: 0.015625 MB
Total new allocate blocks : 2,Total size is: 0.031250 MB
Total insert buf bitmap blocks : 1,Total size is: 0.015625 MB
Total system blocks : 0,Total size is: 0.000000 MB
Total transaction system blocks: 0,Total size is: 0.000000 MB
Total file space header blocks : 1,Total size is: 0.015625 MB
Total extrenl disc blocks : 0,Total size is: 0.000000 MB
Total LOB blocks : 0,Total size is: 0.000000 MB
Total Unkown blocks : 0,Total size is: 0.000000 MB

可以看到
current read blocks is : 3 –This Block is data blocks(index pages)!
就是实际的数据，因为我这里只有
mysql select * from km1;
+——+———+
| id | name |
+——+———+
| 2 | gaopeng |
| 4 | gaopeng |
| 5 | gaopeng |
| 6 | gaopeng |
| 7 | gaopeng |
| 8 | gaopeng |
+——+———+
6 rows in set (0.04 sec)

6 行数据，并且是上次测试留下了，这些数据部分是从用的 DELETE 的空间，当然这也就是说，你的 INSERT 并不一定在文件中是顺序存储的，
因为 delete 的空间会被重用。

[root@hadoop1 test]# bcview km1.ibd 16 94 26|more
******************************************************************
This Tool Is Uesed For Find The Data In Binary format(Hexadecimal)
Usage:./bcview file blocksize offset cnt-bytes!
file: Is Your File Will To Find Data!
blocksize: Is N kb Block.Eg: 8 Is 8 Kb Blocksize(Oracle)!
Eg: 16 Is 16 Kb Blocksize(Innodb)!
offset:Is Every Block Offset Your Want Start!
cnt-bytes:Is After Offset,How Bytes Your Want Gets!
Edtor QQ:22389860!
Used gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)
******************************************************************
—-Current file size is :0.093750 Mb
—-Current use set blockszie is 16 Kb
current block:00000000–Offset:00094–cnt bytes:26–data is:00000000ffffffff0000ffffffff000000000000000000030000
current block:00000001–Offset:00094–cnt bytes:26–data is:0000000000000000000000000000000000000000000000000000
current block:00000002–Offset:00094–cnt bytes:26–data is:00000000ffffffff0000ffffffff000005d669d200000003ffff
current block:00000003–Offset:00094–cnt bytes:26–data is:0100020041696e66696d756d0007000b000073757072656d756d
current block:00000004–Offset:00094–cnt bytes:26–data is:0000000000000000000000000000000000000000000000000000
current block:00000005–Offset:00094–cnt bytes:26–data is:0000000000000000000000000000000000000000000000000000

我们只研究数据块 current block:00000003 的实际数据
current block:00000003–Offset:00094–cnt bytes:26–data is:0100020041696e66696d756d0007000b000073757072656d756d
分解一下:

0100020041696e66696d756d00 为 infimum 的相关信息
07000b000073757072656d756d 为 SPREMUM 的相关信息

1、info flags
4 位
0X0 infimum
0X0 supremum
infimum 和 supremum 行在我测试数据库中为 binary 0000
2、number of records owned
4 位
0X1 infimum binary 0001 1 行
0X7 supremum binary 0111 7 行
3、order
由于 13 位不能转化为 16 进制直接给出二进制 binary
infimum 0X0002 两字节 0000 0000 0000 0010
supermum 0X000b 两字节 0000 0000 0000 1011
binary 0000 0000 0000 0 infimum 可以看到确实 infimum 在这 13 位上为 0
binary 0000 0000 0000 1 supermum 可以看到确实 supermum 在这 13 位上为 1

4、record type
infimum 3 位为 binary 010 及 10 进制的 2 可以看到确实 infimum 恒等于 2 及 binary 010
supermum 3 位为 binary 011 及 10 进制的 3 可以看到确实 supermum 恒等于 3 及 binary 011

5、next record offset
infimum 2 个字节为 0X0041 这里 infimum 指向了下一个行的指针
supermum 2 个字节为 0X0000 这里 supermum 为空指针 0X0000

那么我们就要看看 infimum 的指针 0X0041 是不是指向的数据了，
0X0041 十进制为 65，这个位置是 infimum header 结束位置相对偏移量及 99
我们知道 int 类型为 4BYTES 而我的数据 gaopeng 为 7 字节
那么就是 11 字节
同时在我们的页数据块，当然我这里就一个块当然也就是页块了
他的数据结构实际如下：
CLUSTER KEY FIELDS 主键字节数，我这里没有就是 ROWID，6 字节
transaction id 固定 6 字节
roll pointer 固定 7 字节
Non-key fields 就是数据的字节数，我这里就是 11 字节了
那么我们可以算出起始位置为 99+65=164 查看的字节数为 11+6+6+7=30
注意这里的偏移量为 65 很显然，这里不是物理的第一行，order 排序的第一行。order 就是插入的顺序，原来的第一行被我 DELETE 掉了，空间重用过了。

bcview km1.ibd 16 164 30|more
current block:00000003–Offset:00164–cnt bytes:30–data is:000001cc64260000002d0272d300000d1201108000000267616f70656e67
分解一下数据
000001cc6426 ROWID
0000002d0272 transaction id
d300000d120110 roll pointer
80000002 数据 2，这里 8 出现在第 15 位，可能为符号位
67616f70656e67 数据 gaopeng 的 ascII 值

可以看到没有问题，我们找到了他的数据，由于 ROW HEADER 是可变的，所以这个指针指向是数据的开头，而不包含行头
行头信息需要计算 offset 后像前面偏移 N 个字节开始，当然这内容以后再讨论
关于行的格式会在以后的文章中给出，这里重要解释 infimum 和 supermum，

6、infimum\0 和 supermum

这个没什么好说的就是 ASCII 值
696e66696d756d00= infimum\0
73757072656d756d= supermum

最后
这里在做一个测试试一下 bigint UNSIGNED 类型
首先测试 bigint 是否为 8 个字节，同时测试符号位
mysql create table km15(id bigint UNSIGNED ,name varchar(20));
Query OK, 0 rows affected (0.15 sec)
mysql insert into km15 values(10, gaopeng
Query OK, 1 row affected (0.02 sec)
同样不需要主键
bcview km15.ibd 16 94 26|more
current block:00000003–Offset:00094–cnt bytes:26–data is:010002001c696e66696d756d0002000b000073757072656d756d
分解数据
010002001c696e66696d756d00 infimum
02000b000073757072656d756d supermum
infimum 行的偏移量 001c=28
99+28=127
CLUSTER KEY FIELDS 主键字节数，我这里没有就是 ROWID，6 字节
transaction id 固定 6 字节
roll pointer 固定 7 字节
Non-key fields 就是数据的字节数，我这里就是 8(bigint)+ 7 字节了 =15 字节
bcview km15.ibd 16 127 34|more
current block:00000003–Offset:00127–cnt bytes:34–data is:000001cc680a0000002d0e74e0000080240110000000000000000a67616f70656e67
分解数据
000001cc680a
0000002d0e74
e0000080240110
000000000000000a 实际数据 10
67616f70656e67 数据 goapeng
没有问题 bigint UNSIGNED 为 8 字节同时没有了符号位当然没有符号位存储的数据最大也就是 2^64 如果有符号当然少一位
就是 -2^32 到 2^32 如果有 C 语言的基础也就不难理解了。

到此，关于“INNODB SYSTEM RECORD infimum 和 supremum 的举例分析”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注丸趣 TV 网站，丸趣 TV 小编会继续努力为大家带来更多实用的文章！

正文完