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

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

四、主键和普通索引叶子节点的行数据在存储上有哪些区别?

下面我先总结一下:

  • 主键会包含全部的字段,普通索引只会包含它定义的字段内容
  • 主键会包含trx id和roll ptr,普通索引不会包含
  • 即便不定义主键也会包含一个根据rowid排列的聚集索引,很明显如果不定义普通索引则不会存在
  • 普通索引叶子结点包含了主键或者rowid

下面我们验证一下,我们来观察第2行数据,即:

  1. |  2| gaopeng | NULL    | gaopeng |

在主键上这条记录存在于(offset:180)中,在普通索引这条记录存在于(offset:137)中,下面我们分别解析:

主键(block 3 offset 180 ):

  1. [root@gp1 test]# ./bcview baguait1.ibd 1618050|grep 00000003
  2. current block:00000003--Offset:00180--cnt bytes:50--data is:8000000200000005d96adc00000042011067616f70656e6767616f70656e6720202020202020202020202020070600002000

解析一下:

  • 80000002:主键
  • 00000005d96a:trx id 6字节
  • dc000000420110:undo ptr 7字节
  • 67616f70656e67:第二个字段的‘gaopeng’的ASCII编码
  • 67616f70656e6720202020202020202020202020:第四个字段的‘gaopeng’的ASCII编码,并且因为是char(20)类型因此出现了0X20补足的情况,这实际上也解决了第5个问题,我们可以实实在在的看到这种补足操作,占用了更多的空间。

这里我们发现这条记录没有第三个字段,因为其为NULL,其包含在NULL位图中,后面我们会说明。

普通索引(block 4 offset 137 ):

[root@gp1 test]# ./bcview baguait1.ibd 
16
137
20
|grep 
00000004
current block:
00000004
--
Offset
:
00137
--cnt bytes:
20
--data 
is
:
67616f70656e67800000020700000020ffd56761

解析如下:

  • 67616f70656e67:‘gaopeng’的ASCII编码
  • 80000002:主键值2

后面的内容是下一行的行头了,这一点如果不确定可以看看最后一行,最后一行的位置是(offset:173)查看如下:


[root@gp1 test]# ./bcview baguait1.ibd 
16
173
20
|grep 
00000004
current block:
00000004
--
Offset
:
00173
--cnt bytes:
20
--data 
is
:
6180000004000000000000000000000000000000

解析为:

  • 61:‘a’的ASCII编码
  • 80000004:主键值4

后面是0了,我们这里可以看到没有trx id和roll ptr,除了键值以外普通索引还包含了主键。

五、char和varchar在存储上的区别?

这一点我在上面已经说了,下面我们还是以第二行数据为例:

  1. |  2| gaopeng | NULL    | gaopeng |

其中第1个‘gaopeng’是varchar(20)第2个‘gaopeng’是char(20)下面是他们的存储方式:

  • 67616f70656e67:第二个字段的‘gaopeng’的ASCII编码
  • 67616f70656e6720202020202020202020202020:第四个字段的‘gaopeng’的ASCII编码,并且因为是char(20)类型因此出现了0X20补足20字节的情况,我们可以实实在在的看到这种补足操作,占用了更多的空间。

不再过多熬述

六、数据中的NULL值如何存储的?

这一点还记得‘行头’的NULL位图吗?实际上这个位图会为每一个可以为NULL的字段预留1位的空间,用于标记是否字段的值为NULL,当然至少1字节(8位)。

+----+---------+---------+---------+
| id | c1      | c2      | c3      |
+----+---------+---------+---------+
|  
1
| NULL    | gaopeng | gaopeng |
|  
2
| gaopeng | NULL    | gaopeng |
|  
3
| gaopeng | NULL    | NULL    |
|  
4
| a       | NULL    | NULL    |
+----+---------+---------+---------+

c1\c2\c3均可以为空,因此我们分别访问4条记录聚集索引(block 3)上的NULL位图信息,计算方式如下:

  • 第1行:记录(offset:128)那么128-5(5字节固定)-1(1字节NULL位图)= 122
  • 第2行:记录(offset:180)那么180-5(5字节固定)-1(1字节NULL位图)= 174
  • 第3行:记录(offset:231)那么231-5(5字节固定)-1(1字节NULL位图)= 225
  • 第4行:记录(offset:262)那么262-5(5字节固定)-1(1字节NULL位图)= 256

好了有了偏移量我们可以使用bcview访问这1字节的NULL位图信息了如下:

第1行 [root@gp1 test]# ./bcview baguait1.ibd 16 122 1 |grep 00000003 current block:00000003--Offset:00122--cnt bytes:01--data is:01 转换为二进制为:0000 0001

第2行 [root@gp1 test]# ./bcview baguait1.ibd 16 174 1 |grep 00000003 current block:00000003--Offset:00174--cnt bytes:01--data is:02 转换为二进制为:0000 0010

第3行 [root@gp1 test]# ./bcview baguait1.ibd 16 225 1 |grep 00000003 current block:00000003--Offset:00225--cnt bytes:01--data is:06 转换为二进制为:0000 0110

第4行 [root@gp1 test]# ./bcview baguait1.ibd 16 256 1 |grep 00000003 current block:00000003--Offset:00256--cnt bytes:01--data is:06 转换为二进制为:0000 0110

下面就是NULL位图的表示方法,1为NULL,我们发现和我们记录中的NULL记录一模一样。


c3 c2 c1
第1行 0 0 1
第2行 0 1 0
第3行 1 1 0
第4行 1 1 0

我们DDL修改字段的NULL属性的时候并不能通过修改数据字典来快速完成,我觉得修改更改ibd文件的实际内容是其中很大的一部分原因。下面是我修改NULL属性的记录,具体参考官方文档。

设置NULL和NOT NULL属性
都是inplace方式,因为需要修改NULL位图 因此都需要重组,代价较高
ALTER TABLE tbl_name MODIFY COLUMN column_name data_type NULL, ALGORITHM=INPLACE, LOCK=NONE;
ALTER TABLE tbl_name MODIFY COLUMN column_name data_type NOT NULL, ALGORITHM=INPLACE, LOCK=NONE;


相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。   相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情: https://www.aliyun.com/product/rds/mysql 
相关文章
|
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
|
9月前
|
SQL 关系型数据库 MySQL
【YashanDB知识库】字符集latin1的MySQL中文数据如何迁移到YashanDB
本文探讨了在使用YMP 23.2.1.3迁移MySQL Server字符集为latin1的中文数据至YashanDB时出现乱码的问题。问题根源在于MySQL latin1字符集存放的是实际utf8编码的数据,而YMP尚未支持此类场景。文章提供了两种解决方法:一是通过DBeaver直接迁移表数据;二是将MySQL表数据转换为Insert语句后手动插入YashanDB。同时指出,这两种方法适合单张表迁移,多表迁移可能存在兼容性问题,建议对问题表单独处理。
【YashanDB知识库】字符集latin1的MySQL中文数据如何迁移到YashanDB

推荐镜像

更多