本文介绍: 这也正对了前面说到的最左原则特性。之前理论知识也说过了,目录页会记录最小索引编号,来作为目录检索比如查询34000,那就是在33819~34232区间指向page 6 号数据里面这个时候就会去6号page检索这里可以看到查看page为3(PRIMARY索引root页)的页信息后,一共出来95个page信息对应了上述表述的95个leaf page,同时默认按照主键ID从小到大排序可以看出来在二级索引leaf节点中,是没有完整数据信息的,处理索引数据,还存储主键id信息

达在之前已经分享过Innodb数据存储结构知识,但是都是基于理论原理知识理解今天利用Innodb文件解析工具ruby进行探索Innodb真实的存储结构。

索引原理过程【Mysql】 InnoDB引擎深入 – 数据页 | 聚集索引_innodb的聚集索引的数据插入_Survivor001的博客-CSDN博客

Innodb_ruby工具安装过程分享过,这里就不阐述了,具体的使用方法可以查看官网git上面的介绍Home · jeremycole/innodb_ruby Wiki · GitHub

1、场景描述

这里我创建简单的一些表:project用来验证不同的理论原理知识:

project 表约2.3w笔数据

主键索引:project_id

唯一索引:index(`tenantsid`, `code`)

简单说下innodb_space语法

innodb_space命令行使用基础知识。有两种方法可以开始innodb_space

针对单个空间文件ibdata 或 .ibd):

选项 参数 描述
-F <文件名> 加载空间文件系统或表)

针对自动加载每个文件的表空间文件系统空间

选项 参数 描述
s <文件名> 加载系统空间文件例如ibdata1)
-T <表名> 使用给定表名称。
-I <索引名称> 使用给定的索引名称

注:使用innodb_space查看空间数据需要进入mysql数据存储目录,我的目录

/usr/local/mysql/data

2、通过Innodb_space查看系统空间信息

innodb_space -s ibdata1 system-spaces;

pages:总数据页数量,这里project表,一共使用到了704个 page

indexes:总索引个数project表我这里就是聚簇索引和唯一索引,分别就是PRIMARY主键index(`tenantsid`, `code`)索引。

3、指定查看索引空间信息 

innodb_space -s ibdata1 -T firestation/project space-indexes;

 id :索引ID,相同的ID表示是同一个索引

root当前索引的根page页编号可以看出来

fseg:类型page的说明

used:索引使用到了多少page页,比如PRIMARY的叶子类型中为95,表明使用到了95个page页来存储数据(因为聚簇索引叶子节点存储了数据信息

allocated分配多少page

fill_factor:page使用占比 :used / allocated

这里表示

PRIMARY 索引树使用使用了1个root节点,该节点根page编号为3,leaf节点数据为95个page,实际分配了96个数据页。这里可以看出来,PRIMARY索引树是一个2层的多叉树结构:

 

二级索引 index:1个root节点,page编号为7,leaf节点为42个page,实际分配了96个page,也是一个2层多叉树

1、查看节点page空间信息

  已经知道了大致的索引结构了,现在可以详细查看一下指定page页信息

(1)查看主键PRIMARY root页面空间信息

innodb_space -s ibdata1 -T firestation/project -p 3 page-records

 这里可以看到在查看了page为3(PRIMARY索引的root页)的页信息后,一共出来95个page信息,对应了上述表述的95个leaf page,同时默认按照主键ID从小到大排序

之前理论知识也说过了,目录页会记录最小索引列编号,来作为目录检索,比如查询34000,那就是在33819~34232区间指向page 6 号数据页里面这个时候就会去6号page页检索。

所以理论上来说,page5 页中应该存储了33649~33818之间的数据,下面来验证

2、查看指定leaf-page空间信息

innodb_space -s ibdata1 -T firestation/project -p 5 page-records

这个打印出来内容比较多,因为所有数据都被展示了,这里我截取前后id的信息:

这里可以看到个数据是33649 , 结尾数据是33818,同时也发现了PRIMARY索引的leaf节点里面是有真实数据信息的。但是非叶子节点只有索引列信息,也就是主键ID。

(2)同样操作查看二级索引index空间信息

可以看出来二级索引page数量明显少于聚簇索引page,因为二级索引是不存储其他业务数据字段信息的,所以每个page能存储更多的索引列信息。

同时可以发现联合索引,在nonleaf节点中存储了联合索引列,tenantsid 和 code两个字段信息,且优先索引列顺序,同时优先对tenantsid进行排序然后code进行排序。这也正对了前面说到的最左原则特性。

然后看看leaf节点信息:

可以看出来在二级索引的leaf节点中,是没有完整的数据信息的,处理索引列数据,还存储了主键id信息。这也验证前面说到的,二级索引查询完成后会通过主键ID查询聚簇索引树。

到这里基本上已经完全了解了Innodb索引数据存储原理

有个问题

为什么前面查看系统空间发现project总共使用了704个page,但是通过index空间查看使用到的page数量远小于这个数。

查看系统page使用和分布:

可以看出来,处理真实使用到索引数之外,还会有其他page存储数据,比如缓存、元空间信息等等,后续再详细分享

原文地址:https://blog.csdn.net/qq_31142237/article/details/134715296

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任

如若转载,请注明出处:http://www.7code.cn/show_32194.html

如若内容造成侵权/违法违规/事实不符,请联系代码007邮箱suwngjj01@126.com进行投诉反馈,一经查实,立即删除

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注