MySQL:如何快速的查看Innodb数据文件(1)

简介: MySQL:如何快速的查看Innodb数据文件

注意:本文很多输出格式是16进制格式。

使用版本:MySQL 5.7.22

经常有朋友问我一些如何查看Innodb数据文件的问题,比如:

  • 如果我是UTF8字符集,如果插入字符‘a’到底占用几个字节 ?
  • 主键和普通索引叶子节点的行数据在存储上有哪些区别?
  • 如何证明rowid的存在?
  • 数据中的NULL值如何存储的?
  • char和varchar在存储上的区别?......

如果要得到答案除了学习源码,可能更加直观的方式就是查看Innodb的ibd数据文件了,俗话说得好“眼见为实”,但是我们知道数据文件是二进制形式的,Innodb通过既定的访问方式解析出其中的格式得到正确的结果。如果我们要去访问这些ibd文件,通常的方式就是可以通过hexdump -Cv这样的命令进行二进制的访问,最初我也是这样访问的,但是看起来眼睛特别难受。因此我写了2个工具:

  • innblock:一个用于解析数据块的工具,能够得到每行的偏移量,并且按照逻辑和物理顺序排序。
    详细使用方式可以参考: https://mp.weixin.qq.com/s/yfi5XikDJlh6-nS-eoJbcA
    下载地址:
    https://github.com/gaopengcarl/innblock

    除了代码我已经编译好了直接使用即可

  • bcview:一个小工具,用于将数据文件按照既定的大小(比如16K)分块,然后访问每个块的偏移量后指定的字节数,通常我们并不知道记录到底多长,可以设置一个较大的查看字节数。
    下载地址:
    https://github.com/gaopengcarl/bcview
    除了代码我已经编译好了直接使用即可

有了这两工具可能访问ibd数据文件就更加方便一些了,下面我就使用这两个工具来进行数据文件的查看,来解决开头我们提出的这些问题。

一、行结构简述

本文无意解释详细的Innodb文件结构,这样的文章和书籍很多,比如:

整个系列都是讲解Innodb文件结构的,我们只需要知道普通数据块,除去块级别的开销后,其第一行记录从偏移量94 开始,首先出现的是2个伪列 infimum 和 supremum,它们的位置固定在块的94-120字节,其中94-107为infimum 相关信息,而107到120为supremum相关信息,分别的heap no 为 0和1,它们是逻辑记录的开始和结尾,所有的实际的记录都链接在这一条链表上。

其中普通记录的大概格式如下:

image.png

我暂且将黄色部分称为‘行头’,图中用粉红色标记的innblock每行数据offset的位置,我们发现innblock工具指向的是行头以后实际字段开启的位置

下面是一个innblock工具典型的部分输出:

-----
Total
 used rows:
3
 used rows list(logic):
(
1
) INFIMUM record offset:
99
 heapno:
0
 n_owned 
1
,delflag:N minflag:
0
 rectype:
2
(
2
) normal record offset:
128
 heapno:
2
 n_owned 
0
,delflag:N minflag:
0
 rectype:
0
(
3
) SUPREMUM record offset:
112
 heapno:
1
 n_owned 
2
,delflag:N minflag:
0
 rectype:
3
-----
Total
 used rows:
3
 used rows list(phy):
(
1
) INFIMUM record offset:
99
 heapno:
0
 n_owned 
1
,delflag:N minflag:
0
 rectype:
2
(
2
) SUPREMUM record offset:
112
 heapno:
1
 n_owned 
2
,delflag:N minflag:
0
 rectype:
3
(
3
) normal record offset:
128
 heapno:
2
 n_owned 
0
,delflag:N minflag:
0
 rectype:
0

我们可以找到一行除了infimum和 supremum记录以外的normal记录,并且标记了这样记录字段的起点(offset:128),也就是图中的粉红色部分,但是需要注意的是聚集索引(表本身)而言,如果没有主键前面3列分别为:

  • rowid 6字节
  • trx id 6字节
  • roll ptr 7字节

如果存在主键则为:

  • 主键 和定义有关
  • trx id 6字节
  • roll ptr 7字节

关于rowid\trx id\roll ptr的源码中的定义如下:

  1. #define    DATA_ROW_ID 0/* row id: a 48-bit integer */
  2. #define DATA_ROW_ID_LEN    6/* stored length for row id */

  3. #define DATA_TRX_ID    1/* transaction id: 6 bytes */
  4. #define DATA_TRX_ID_LEN    6

  5. #define    DATA_ROLL_PTR   2/* rollback data pointer: 7 bytes */
  6. #define DATA_ROLL_PTR_LEN 7

而roll ptr的具体含义可以参考函数trx_undo_decode_roll_ptr如下:

  1. /***********************************************************************//**
  2. Decodes a roll pointer. */
  3. //从高位到低位依次是
  4. //第1位是否是insert
  5. //第2到8位是segmentid
  6. //第9到40位为page no
  7. //第41位到56位为OFFSET
  8. UNIV_INLINE
  9. void
  10. trx_undo_decode_roll_ptr(
  11. /*=====================*/
  12. roll_ptr_t  roll_ptr,   /*!< in: roll pointer */
  13.    ibool*      is_insert,  /*!< out: TRUE if insert undo log */
  14.    ulint*      rseg_id,    /*!< out: rollback segment id */
  15.    ulint*      page_no,    /*!< out: page number */
  16.    ulint*      offset)     /*!< out: offset of the undo
  17.                    entry within page */
  18. {
  19. ...
  20.    ut_ad(roll_ptr < (1ULL<< 56));
  21. *offset = (ulint) roll_ptr & 0xFFFF; //获取低16位 为OFFSET
  22.    roll_ptr >>= 16; //右移16位
  23. *page_no = (ulint) roll_ptr & 0xFFFFFFFF;//获取32位为 page no
  24.    roll_ptr >>= 32;//右移32位
  25. *rseg_id = (ulint) roll_ptr & 0x7F;//获取7位为segment id
  26.    roll_ptr >>= 7;//右移7位
  27. *is_insert = (ibool) roll_ptr; /* TRUE==1 *///最后一位
  28. }


二、建立测试表

为了解决文中开头的几个问题,我们来建立测试表如下:

  1. drop table baguait1;
  2. create table baguait1(id int primary key,c1 varchar(20) ,c2 varchar(20),c3 char(20)) ENGINE=InnoDB DEFAULT CHARSET=utf8;
  3. alter table baguait1 add key(c1);

  4. insert into baguait1 values(1,NULL,'gaopeng','gaopeng');
  5. insert into baguait1 values(2,'gaopeng',NULL,'gaopeng');
  6. insert into baguait1 values(3,'gaopeng',NULL,NULL);
  7. insert into baguait1 values(4,'a',NULL,NULL);

  8. mysql> select* from baguait1;
  9. +----+---------+---------+---------+
  10. | id | c1      | c2      | c3      |
  11. +----+---------+---------+---------+
  12. |  1| NULL    | gaopeng | gaopeng |
  13. |  2| gaopeng | NULL    | gaopeng |
  14. |  3| gaopeng | NULL    | NULL    |
  15. |  4| a       | NULL    | NULL    |
  16. +----+---------+---------+---------+
  17. 4 rows inset(0.01 sec)

我们发现这里实际上除了rowid问题还不能包含,其他都包含了,接下来我们使用innblock进行扫描。如下:

1、扫描数据文件找到主键和普通索引数据块

  1. [root@gp1 test]# ./innblock baguait1.ibd scan 16
  2. ···
  3. DatafileTotalSize:114688
  4. ===INDEX_ID:323
  5. level0 total block is(1)
  6. block_no:         3,level:   0|*|
  7. ===INDEX_ID:324
  8. level0 total block is(1)
  9. block_no:         4,level:   0|*|


这里实际上323就是聚集索引,324就是普通索引,它们数据块对应是3和4。

2、扫描聚集索引记录

  1. 16

  2. 链表部分:
  3. ==== Block list info ====
  4. -----Total used rows:6 used rows list(logic):
  5. (1) INFIMUM record offset:99 heapno:0 n_owned 1,delflag:N minflag:0 rectype:2
  6. (2) normal record offset:128 heapno:2 n_owned 0,delflag:N minflag:0 rectype:0
  7. (3) normal record offset:180 heapno:3 n_owned 0,delflag:N minflag:0 rectype:0
  8. (4) normal record offset:231 heapno:4 n_owned 0,delflag:N minflag:0 rectype:0
  9. (5) normal record offset:262 heapno:5 n_owned 0,delflag:N minflag:0 rectype:0
  10. (6) SUPREMUM record offset:112 heapno:1 n_owned 5,delflag:N minflag:0 rectype:3
  11. -----Total used rows:6 used rows list(phy):
  12. (1) INFIMUM record offset:99 heapno:0 n_owned 1,delflag:N minflag:0 rectype:2
  13. (2) SUPREMUM record offset:112 heapno:1 n_owned 5,delflag:N minflag:0 rectype:3
  14. (3) normal record offset:128 heapno:2 n_owned 0,delflag:N minflag:0 rectype:0
  15. (4) normal record offset:180 heapno:3 n_owned 0,delflag:N minflag:0 rectype:0
  16. (5) normal record offset:231 heapno:4 n_owned 0,delflag:N minflag:0 rectype:0
  17. (6) normal record offset:262 heapno:5 n_owned 0,delflag:N minflag:0 rectype:0

3、扫描普通索引记录

  1. [root@gp1 test]# ./innblock baguait1.ibd 4 16

  2. 链表部分:
  3. ==== Block list info ====
  4. -----Total used rows:6 used rows list(logic):
  5. (1) INFIMUM record offset:99 heapno:0 n_owned 1,delflag:N minflag:0 rectype:2
  6. (2) normal record offset:126 heapno:2 n_owned 0,delflag:N minflag:0 rectype:0
  7. (3) normal record offset:173 heapno:5 n_owned 0,delflag:N minflag:0 rectype:0
  8. (4) normal record offset:137 heapno:3 n_owned 0,delflag:N minflag:0 rectype:0
  9. (5) normal record offset:155 heapno:4 n_owned 0,delflag:N minflag:0 rectype:0
  10. (6) SUPREMUM record offset:112 heapno:1 n_owned 5,delflag:N minflag:0 rectype:3
  11. -----Total used rows:6 used rows list(phy):
  12. (1) INFIMUM record offset:99 heapno:0 n_owned 1,delflag:N minflag:0 rectype:2
  13. (2) SUPREMUM record offset:112 heapno:1 n_owned 5,delflag:N minflag:0 rectype:3
  14. (3) normal record offset:126 heapno:2 n_owned 0,delflag:N minflag:0 rectype:0
  15. (4) normal record offset:137 heapno:3 n_owned 0,delflag:N minflag:0 rectype:0
  16. (5) normal record offset:155 heapno:4 n_owned 0,delflag:N minflag:0 rectype:0
  17. (6) normal record offset:173 heapno:5 n_owned 0,delflag:N minflag:0 rectype:0

我们发现不管聚集索引还是普通索引均包含了4条普通记录,并且采集到了记录的偏移量,我们需要注意一下这里普通索引的逻辑链表顺序中我们可以看到第4条记录(offset:173 )已经排到了第3位,实际上它是最后插入的,这是因为‘a’字符的顺序肯定是在‘gaopeng’这个字符串之前的。并且第一行记录C1为NULL它在逻辑链表顺序中依然是在第一位。好了下面我们就来将问题逐一解决。

三、如果我是UTF8字符集,如果插入字符‘a’到底占用几个字节 ?

在我们的语句中我们最后一条记录插入的数据就是'a',即:

  1. |  4| a       | NULL    | NULL    |

我们使用bcview来查看一下聚集索引 (offset 262 )的数据是啥,我们直接从块3的(offset 262 )后查看20个字节,如下:

  1. [root@gp1 test]# ./bcview baguait1.ibd 1626230|grep 00000003
  2. current block:00000003--Offset:00262--cnt bytes:30--data is:8000000400000005d970e000000043011061000000000000000000000000

我们来解析一样:

  • 80000004:主键4,8是符号位
  • 400000005d970:trx id 6字节
  • e0000000430110:undo ptr 7字节
  • 61:字符‘a’,ASCII编码

我们发现后面都是0了,实际上字符‘a’即便在UTF8字符下也只是占用一个字节而已。


相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。 &nbsp; 相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情:&nbsp;https://www.aliyun.com/product/rds/mysql&nbsp;
相关文章
|
7月前
|
缓存 NoSQL 关系型数据库
美团面试:MySQL有1000w数据,redis只存20w的数据,如何做 缓存 设计?
美团面试:MySQL有1000w数据,redis只存20w的数据,如何做 缓存 设计?
美团面试:MySQL有1000w数据,redis只存20w的数据,如何做 缓存 设计?
|
5月前
|
SQL 人工智能 关系型数据库
如何实现MySQL百万级数据的查询?
本文探讨了在MySQL中对百万级数据进行排序分页查询的优化策略。面对五百万条数据,传统的浅分页和深分页查询效率较低,尤其深分页因偏移量大导致性能显著下降。通过为排序字段添加索引、使用联合索引、手动回表等方法,有效提升了查询速度。最终建议根据业务需求选择合适方案:浅分页可加单列索引,深分页推荐联合索引或子查询优化,同时结合前端传递最后一条数据ID的方式实现高效翻页。
307 0
|
3月前
|
存储 关系型数据库 MySQL
介绍MySQL的InnoDB引擎特性
总结而言 , Inno DB 引搞 是 MySQL 中 高 性 能 , 高 可靠 的 存 储选项 , 宽泛 应用于要求强 复杂交易处理场景 。
155 15
|
8月前
|
存储 网络协议 关系型数据库
MySQL8.4创建keyring给InnoDB表进行静态数据加密
MySQL8.4创建keyring给InnoDB表进行静态数据加密
280 1
|
4月前
|
存储 关系型数据库 MySQL
在CentOS 8.x上安装Percona Xtrabackup工具备份MySQL数据步骤。
以上就是在CentOS8.x上通过Perconaxtabbackup工具对Mysql进行高效率、高可靠性、无锁定影响地实现在线快速全量及增加式数据库资料保存与恢复流程。通过以上流程可以有效地将Mysql相关资料按需求完成定期或不定期地保存与灾难恢复需求。
395 10
|
5月前
|
SQL 存储 缓存
MySQL 如何高效可靠处理持久化数据
本文详细解析了 MySQL 的 SQL 执行流程、crash-safe 机制及性能优化策略。内容涵盖连接器、分析器、优化器、执行器与存储引擎的工作原理,深入探讨 redolog 与 binlog 的两阶段提交机制,并分析日志策略、组提交、脏页刷盘等关键性能优化手段,帮助提升数据库稳定性与执行效率。
157 0
|
6月前
|
SQL 关系型数据库 MySQL
MySQL 5.6/5.7 DDL 失败残留文件清理指南
通过本文的指南,您可以更安全地处理 MySQL 5.6 和 5.7 版本中 DDL 失败后的残留文件,有效避免数据丢失和数据库不一致的问题。
|
8月前
|
关系型数据库 MySQL Linux
在Linux环境下备份Docker中的MySQL数据并传输到其他服务器以实现数据级别的容灾
以上就是在Linux环境下备份Docker中的MySQL数据并传输到其他服务器以实现数据级别的容灾的步骤。这个过程就像是一场接力赛,数据从MySQL数据库中接力棒一样传递到备份文件,再从备份文件传递到其他服务器,最后再传递回MySQL数据库。这样,即使在灾难发生时,我们也可以快速恢复数据,保证业务的正常运行。
397 28
|
7月前
|
存储 SQL 缓存
mysql数据引擎有哪些
MySQL 提供了多种存储引擎,每种引擎都有其独特的特点和适用场景。以下是一些常见的 MySQL 存储引擎及其特点:
211 0
|
8月前
|
SQL 缓存 关系型数据库
使用温InnoDB缓冲池启动MySQL测试
使用温InnoDB缓冲池启动MySQL测试
154 0

推荐镜像

更多