04 mysql innodb record

这篇具有很好参考价值的文章主要介绍了04 mysql innodb record。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

前言 

最近看到了 何登成 大佬的 "深入MySQL源码 -- Step By Step" 的 pdf 呵呵 似乎是找到了一些 方向 

之前对于 mysql 方面的东西, 更多的仅仅是简单的使用[业务中的各种增删改查], 以及一些面试题的背诵 

这里会参照 MySQL Internals Manual 来大致的看一下 innodb 里面的 record 的存储相关, 这些是深入了解 mysql 的基础 

我们这里主要是会了解一下两种 RowFormat : Redundant 和 Compact 

本文内容对应的是 mysql调试的一些基础方法 里面的 查看一下 rec 的数据信息

MySQL Internals Manual - 22.1 InnoDB Record Structure

以下截图参照自 MySQL Internals Manual 

这里的说明是基于 RowFormat - Redundant 

总的来说一个 record 分成了三个部分 : 各个字段的偏移(Field Start Offsets), 元数据信息(Extra Bytes), 记录信息(Field Contents) 

Field Start Offsets : 描述的是 record 中的各个字段在 Field Contents 中的偏移, 以此偏移可以确认各个字段的数据信息 

Extra Bytes : 描述的是 record 的元数据, 包括了 删除标记, minRecord标记, 字段数量, "Field Start Offsets" 的单位, 记录编号, 下一个记录的偏移 等等信息 

Field Contents : 里面存储的是具体的数据信息 

22.1.1.3 FIELD CONTENTS 里面介绍了一个实例的案例, 剖析一个实际的记录在内存中的数据分布情况, 以及拆解每一个字节的逻辑意义, 可以移步文档看一下, 这里就不截图了, 请自行查阅文档 

04 mysql innodb record,12 mysql,mysql,record,protocol

04 mysql innodb record,12 mysql,mysql,record,protocol

04 mysql innodb record,12 mysql,mysql,record,protocol

源码中的说明 remOrec.cc | remOrec.ic | remOrec.h

我们再来根据源码中的注释结合 来看一下 

里面注释写的相当详尽, 因此 建议多读注释, 以方便理解 

"深入MySQL源码 -- Step By Step" 里面也提到了 "不放过源码中的每一处注释" 

04 mysql innodb record,12 mysql,mysql,record,protocol

RowFormat - Redundant 

注释里面描述的内容 和 上面 MySQL Internals Manual - 22.1 InnoDB Record Structure 一致 

04 mysql innodb record,12 mysql,mysql,record,protocol

Extra Bytes 的结构信息 

04 mysql innodb record,12 mysql,mysql,record,protocol

RowFormat - Compact 

注释里面描述的内容 就是 Compact 的 RowFormat 的格式了, MySQL Internals Manual 上面我没有找到 

总的来说一个 record 分成了三个部分 : 各个字段的偏移(Field Start Offsets), 元数据信息(Extra Bytes), 记录信息(Field Contents) 

Field Start Offsets : 描述的是 record 中的各个长度可变字段在 Field Contents 中的偏移, table元数据中固定字段偏移 结合 此偏移 可以确认所有字段的偏移, 进而可以确认各个字段的数据信息 

Extra Bytes : 描述的是 record 的元数据, 包括了 null字段标记, 删除标记, minRecord标记, 记录编号, 下一个记录的偏移 等等信息 

Field Contents : 里面存储的是具体的数据信息 

04 mysql innodb record,12 mysql,mysql,record,protocol

Extra Bytes 的结构信息 

04 mysql innodb record,12 mysql,mysql,record,protocol

RowFormat - Redundant 实际案例剖析 

# ROW_FORMAT = Redundant 的内存情况
(lldb) x 0x12c694000 -c 0x100
0x12c694000: 1c 18 8c aa 00 00 00 03 ff ff ff ff ff ff ff ff  ...�....��������
0x12c694010: 00 00 00 00 00 1a b2 d5 45 bf 00 00 00 00 00 00  ......��E�......
0x12c694020: 00 00 00 00 00 07 00 02 00 c6 00 04 00 00 00 00  .........�......
0x12c694030: 00 ad 00 02 00 01 00 02 00 00 00 00 00 00 00 00  .�..............
0x12c694040: 00 00 00 00 00 00 00 00 00 17 00 00 00 07 00 00  ................
0x12c694050: 00 02 00 f2 00 00 00 07 00 00 00 02 00 32 08 01  ...�.........2..
0x12c694060: 00 00 03 00 88 69 6e 66 69 6d 75 6d 00 09 03 00  .....infimum....
0x12c694070: 08 03 00 00 73 75 70 72 65 6d 75 6d 00 1a 15 11  ....supremum....
0x12c694080: 0a 04 00 00 10 0b 00 ad 80 00 00 01 00 00 00 00  .......�........
0x12c694090: 3b 07 87 00 00 01 3a 01 10 80 00 00 1c 6a 65 72  ;.....:......jer
0x12c6940a0: 72 79 19 15 11 0a 04 00 00 18 0b 00 74 80 00 00  ry..........t...
0x12c6940b0: 02 00 00 00 00 3b 08 88 00 00 01 3e 01 10 80 00  .....;.....>....
0x12c6940c0: 00 16 6c 75 63 79 00 00 00 00 00 00 00 00 00 00  ..lucy..........
0x12c6940d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0x12c6940e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0x12c6940f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

# 0x12c694050
0x12c694050: 00 02 00 f2 00 00 00 07 00 00 00 02 00 32 08 01  ...�.........2..
0x12c694060: 00 00 03 00 88 69 6e 66 69 6d 75 6d 00 09 03 00  .....infimum....
0x12c694070: 08 03 00 00 73 75 70 72 65 6d 75 6d 00 1a 15 11  ....supremum....
0x12c694080: 0a 04 00 00 10 0b 00 ad 80 00 00 01 00 00 00 00  .......�........
0x12c694090: 3b 07 87 00 00 01 3a 01 10 80 00 00 1c 6a 65 72  ;.....:......jer
0x12c6940a0: 72 79 19 15 11 0a 04 00 00 18 0b 00 74 80 00 00  ry..........t...
0x12c6940b0: 02 00 00 00 00 3b 08 88 00 00 01 3e 01 10 80 00  .....;.....>....
0x12c6940c0: 00 16 6c 75 63 79 00 00 00 00 00 00 00 00 00 00  ..lucy..........


# infimum = PAGE_OLD_INFIMUM = 0x65
08 : offset of `infimum`
01 : deleted_flag = 0, min_rec_flag = 0, n_owned = 1
00 00 03 : heap_no = 0, n_fields = 1, 1byte_offs_flag = 1
00 88 : next record pointer -> jerry
69 6e 66 69 6d 75 6d 00 : infimum

# supremum = PAGE_OLD_SUPREMUM = 0x74
09 : offset of `supremum`
03 : deleted_flag = 0, min_rec_flag = 0, n_owned = 3
00 08 03 : heap_no = 1, n_fields = 1, 1byte_offs_flag = 1
00 00 : next record pointer -> self
73 75 70 72 65 6d 75 6d 00 : supremum

# record jerry : 0x12c694088 # 格式为 redundant row format
1a 15 11 0a 04 : field offset of id, trx_id, poll_ptr, age, name
00 : deleted_flag = 0, min_rec_flag = 0, n_owned = 0
00 10 0b : heap_no = 2, n_fields = 5, 1byte_offs_flag = 1
00 ad : next record offset -> record lucy

id = 80 00 00 01 = 1
trx_id = 00 00 00 00 3b 07 = 15111
poll_ptr = 87 00 00 01 3a 01 10
age = 80 00 00 1c = 28
name = 6a 65 72 72 79 = jerry

# record lucy : 0x12c6940ad # 格式为 redundant row format
19 15 11 0a 04 : field offset of id, trx_id, poll_ptr, age, name
00 : deleted_flag = 0, min_rec_flag = 0, n_owned = 0
00 18 0b : heap_no = 3, n_fields = 5, 1byte_offs_flag = 1
00 74 : next record offset -> supremum

id = 80 00 00 02 = 2
trx_id = 00 00 00 00 3b 08 = 15112
poll_ptr = 88 00 00 01 3e 01 10
age = 80 00 00 16 = 22
name = 6c 75 63 79 = lucy

RowFormat - Compact 实际案例剖析 

# user 对应的数据 当前页的数据信息, 拆解
(lldb) x 0x1286cc000 -c 0x120
0x1286cc000: 10 aa fb 30 00 00 00 03 ff ff ff ff ff ff ff ff  .��0....��������
0x1286cc010: 00 00 00 00 00 1a a2 7d 45 bf 00 00 00 00 00 00  ......�}E�......
0x1286cc020: 00 00 00 00 00 06 00 02 00 b9 80 04 00 00 00 00  .........�......
0x1286cc030: 00 a0 00 02 00 01 00 02 00 00 00 00 00 00 00 00  .�..............
0x1286cc040: 00 00 00 00 00 00 00 00 00 16 00 00 00 06 00 00  ................
0x1286cc050: 00 02 00 f2 00 00 00 06 00 00 00 02 00 32 01 00  ...�.........2..
0x1286cc060: 02 00 1c 69 6e 66 69 6d 75 6d 00 03 00 0b 00 00  ...infimum......
0x1286cc070: 73 75 70 72 65 6d 75 6d 05 00 00 00 10 00 21 80  supremum......!.
0x1286cc080: 00 00 01 00 00 00 00 2b 07 04 00 00 01 56 04 7b  .......+.....V.{
0x1286cc090: 80 00 00 1c 6a 65 72 72 79 04 00 00 00 18 ff d0  ....jerry.....��
0x1286cc0a0: 80 00 00 02 00 00 00 00 35 04 83 00 00 01 36 01  ........5.....6.
0x1286cc0b0: 10 80 00 00 16 6c 75 63 79 00 00 00 00 00 00 00  .....lucy.......
0x1286cc0c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0x1286cc0d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0x1286cc0e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0x1286cc0f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0x1286cc100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0x1286cc110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

# 0x1286cc050
0x1286cc050: 00 02 00 f2 00 00 00 06 00 00 00 02 00 32 01 00  ...�.........2..
0x1286cc060: 02 00 1c 69 6e 66 69 6d 75 6d 00 03 00 0b 00 00  ...infimum......
0x1286cc070: 73 75 70 72 65 6d 75 6d 05 00 00 00 10 00 21 80  supremum......!.
0x1286cc080: 00 00 01 00 00 00 00 2b 07 04 00 00 01 56 04 7b  .......+.....V.{
0x1286cc090: 80 00 00 1c 6a 65 72 72 79 04 00 00 00 18 ff d0  ....jerry.....��
0x1286cc0a0: 80 00 00 02 00 00 00 00 35 04 83 00 00 01 36 01  ........5.....6.
0x1286cc0b0: 10 80 00 00 16 6c 75 63 79 00 00 00 00 00 00 00  .....lucy.......


# infimum = PAGE_NEW_INFIMUM = 0x63
# infimum : 0x1286cc063
0x0 : delete_flag & min_rec_flag
0x1 : number of records owned by the record
0b 0000 0000 0000 0 = 0 = order number of this record
0b 010 = infimum
0x 00 1c = next record offset -> jerry
69 6e 66 69 6d 75 6d 00 = infimum

# supremum = PAGE_NEW_SUPREMUM = 0x70
# supremum : 0x1286cc070
0x0 : delete_flag & min_rec_flag
0x3 : number of records owned by the record
0b 0000 0000 0000 1 = 1 = order number of this record
0b 011 = supremum
0x 00 00 = next record offset -> self
73 75 70 72 65 6d 75 6d = supremum

# record jerry : 0x1286cc07f # 格式为 compact row format
0x05 : lengthOf('jerry')
0x00 = nulls
0x0 : delete flag
0x0 : number of records owned by the record
0b 0000 0000 0001 0 = 2 = order number of this record
0b 000 = conventional
0x 00 21 : next record offset -> record lucy

rec = 0x80
id = 0x 80 00 00 01 = 1
trx_id = 0x 00 00 00 00 2b 07 = 11015
poll_ptr = 0x 04 00 00 01 56 04 7b
age = 0x 80 00 00 1c = 28
name = 6a 65 72 72 79 = jerry

# record lucy : 0x1286cc0a0 # 格式为 compact row format
0x04 : lengthOf('lucy')
0x00 = nulls
0x0 : delete flag
0x0 : number of records owned by the record
0b 0000 0000 0001 1 = 3 = order number of this record
0b 000 = conventional
0x ff d0 : next record offset -> supremum

rec = 0x80
id = 0x 80 00 00 02 = 2
trx_id = 0x 00 00 00 00 35 04 = 13572
poll_ptr = 0x 83 00 00 01 36 01 10
age = 0x 80 00 00 16 = 22
name = 6c 75 63 79 = lucy

完 

参考

MySQL Internals Manual

深入MySQL源码 -- Step By Step

mysql调试的一些基础方法文章来源地址https://www.toymoban.com/news/detail-652211.html

到了这里,关于04 mysql innodb record的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • MySQL监控Innodb信息

    Innodb由于支持事务操作,是mysql中使用最多的存储引擎,所以如何监控Innodb存储引擎以进行性能优化是在使用mysql过程中遇到最多的,那么如何进行监控呢? show engine show status 通过查看日志文件 缓冲池信息 缓冲池是Innodb缓存频繁访问数据的地方,对缓冲池内数据的任何更新也

    2024年02月20日
    浏览(39)
  • MySQL InnoDB 底层数据存储

    是内存与磁盘交互的基本单位,16kb。 比如,查询的时候,并不是只从磁盘读取某条记录,而是记录所在的页 记录的物理插入是随机的,就是在磁盘上的位置是无序的。但是在页中维护了逻辑顺序,是按照主键从小到大形成的一个单向链表。 infimum与supermum就相当于链表中的头

    2024年01月23日
    浏览(43)
  • MySQL架构 & InnoDB存储引擎

    我们在开发的时候,我们都需要对业务数据进行存储,这个时候,你们就会用到MySQL 、O racal 等数据库。 MySQL它是一个关系型数据库, 这种关系型数据库就有Oracal 、 MySQL,以及最近很火的PgSQL 等。 那什么是关系型数据库呢? 就是它是 基于我们的SQL语句去执行操作的 。 其实

    2024年02月07日
    浏览(50)
  • Mysql进阶- InnoDB引擎架构

    InnoDB的逻辑存储结构如下图所示:  1). 表空间 是InnoDB存储引擎逻辑结构的最高层, 如果用户启用了参数      innodb_file_per_table(在 8.0版本中默认开启) ,则每张表都会有一个表空间(xxx.ibd),一个mysql实例可以对应多个表空间, 用于存储记录、索引等数据 。 2).   段 ,分为

    2024年02月04日
    浏览(43)
  • 【MySQL】InnoDB数据存储结构

    第一部分:文件头部+文件尾部 主要包含了对页面之间双向链表的表示、页面校验和、页面最后被修改对应的日志序列位置 第二部分:空闲空间+用户记录+最小最大记录 用户记录 : ​ 用户记录中的记录按照指定的行格式一条条摆在该区域,相互之间形成单链表。 第三部分:

    2024年01月24日
    浏览(44)
  • 《MySQL系列-InnoDB引擎07》MySQL备份与恢复

    为保证在服务器宕机、磁盘损坏、RAID卡损坏等意外情况下,数据不丢失,或者最小程度的丢失,每个DBA应该时刻关注数据库备份情况。 MySQL数据库提供了大多数工具(如 mysqldump,ibbackup,replication )都能很好的完成备份工作,当然也可以通过第三方工具完成,如 xtrabacup,LVM快照备份

    2024年01月22日
    浏览(44)
  • 深入理解MySQL InnoDB线程模型

    当我们谈论数据库性能时,存储引擎的线程模型是一个不可忽视的方面。MySQL的InnoDB存储引擎,作为目前最受欢迎的存储引擎之一,其线程模型的设计对于实现高并发、高性能的数据操作至关重要。在本文中,我们将深入探讨MySQL InnoDB线程模型的工作原理和关键组件。 在Inn

    2024年01月25日
    浏览(37)
  • MySQL的InnoDB引擎的事务

    MySQL中只有InnoDB支持事务 原子性(atomicity): 原子性是指事务是一个不可分割的工作单位,要么全部提交,要么全部失败回滚。 一致性(consistency): 根据定义,一致性是指事务执行前后,数据从一个 合法性状态 变换到另外一个 合法性状态 。这种状态是 语义上 的而不是

    2024年02月08日
    浏览(38)
  • Mysql架构解析,InnoDB架构概述。

    MySQL整体架构如下图所示: MySQL逻辑系统架构分为4层: 应用层 MySQL服务层 存储引擎层 系统文件层 下面将对各层的功能和组件进行介绍,并探讨一条语句的执行过程。 应用层是MySQL体系架构的最上层,它处理与客户端的交互,主要包含连接处理、用户鉴权和安全管理。 连接处

    2024年02月08日
    浏览(39)
  • Mysql InnoDB行锁深入理解

    Record Lock 称为记录锁,锁住的是一条记录。而且记录锁是有 S 锁和 X 锁之分的: 当一个事务对一条记录加了 S 型记录锁后,其他事务也可以继续对该记录加 S 型记录锁(S 型与 S 锁兼容),但是不可以对该记录加 X 型记录锁(S 型与 X 锁不兼容); 当一个事务对一条记录加了

    2024年01月22日
    浏览(51)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包