html网站建设,深圳福田园岭网站建设,同步WordPress微信公众号,网络规划设计师教程第2版pdf达在之前已经分享过Innodb数据存储结构知识#xff0c;但是都是基于理论原理知识理解#xff0c;今天利用Innodb文件解析工具ruby进行探索Innodb真实的存储结构。
索引原理过程#xff1a;【Mysql】 InnoDB引擎深入 - 数据页 | 聚集索引_innodb的聚集索引的数据插入_Surviv…达在之前已经分享过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
唯一索引indextenantsid, 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主键indextenantsid, 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_factorpage使用占比 used / allocated
这里表示
PRIMARY 索引树使用使用了1个root节点该节点根page编号为3leaf节点数据为95个page实际分配了96个数据页。这里可以看出来PRIMARY索引树是一个2层的多叉树结构: 二级索引 index1个root节点page编号为7leaf节点为42个page实际分配了96个page也是一个2层多叉树 1、查看节点page空间信息 已经知道了大致的索引结构了现在可以详细查看一下指定page页信息
1查看主键PRIMARY root页面空间信息
innodb_space -s ibdata1 -T firestation/project -p 3 page-records 这里可以看到在查看了page为3PRIMARY索引的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能存储更多的索引列信息。
同时可以发现联合索引在non-leaf节点中存储了联合索引列tenantsid 和 code两个字段信息且优先索引列顺序同时优先对tenantsid进行排序然后对code进行排序。这也正对了前面说到的最左原则特性。
然后看看leaf节点信息 可以看出来在二级索引的leaf节点中是没有完整的数据信息的处理索引列数据还存储了主键id信息。这也验证了前面说到的二级索引查询完成后会通过主键ID查询聚簇索引树。 到这里基本上已经完全了解了Innodb索引数据存储原理了
有个问题
为什么前面查看系统空间发现project总共使用了704个page但是通过index空间查看使用到的page数量远小于这个数。
查看系统page使用和分布 可以看出来处理真实使用到索引数之外还会有其他page存储数据比如缓存、元空间信息等等后续再详细分享。
