[转帖]堆表&索引组织表

堆表&索引组织表

https://zhuanlan.zhihu.com/p/487271927

15 人赞同了该文章

很多大佬强调学习一定要看"原版英文材料"。

比如再google搜索堆表和索引组织表，可以看到很多中文加工的材料，比如下面：

实际你随便翻几篇，会发现由于作者的水平限制，整体都讲的云里雾里，导致用户看完更迷茫...(我觉得与其中文材料各种生拉硬扯，为何不把原版材料翻译出来）。

我摘抄几个英文官网的材料来看，直观感受下官方文档的质量：

堆表结构

堆表的材料pg官方文档做的不错(阿里云polar-o也是堆表结构，图表也不错，适合墙内用户(橘黄色))比如：

堆表文件格式

polar-o

堆表数据插入

polar-o

堆表数据查找

索引组织表

索引组织表的材料Jeremy Cole关于innodb材料非常经典做的不错（git图标库）。

innodb的概念里，一切文件皆索引，下面直观体验下：

btree整体结构

btree由page组成，page对应文件中一个16kb片段

Page内部详情

page内部结构图形化展示

Page内部二级索引详情

上图中page内部单链表组成，并且key实际上不一定物理上有序。为了高效再page内进行查找，引入Page Directory Structure，大概4个record组成一个slot，page内record性能可以提升4倍，如下：

内存索引和文件的关系：

上面是从内存或者逻辑角度看索引组织表，实际在用户进行CRUD操作时，会涉及到内存page树和索引文件file的分配和回收等复杂逻辑，该逻辑可以通过下图来描述：

tree -> 文件页面管理

一个索引由一个root page节点来描述，启动时从ibdata的数据词典表中load元数据信息，其中SYS_INDEXES系统表中记录了表，索引及索引根页对应的page no（DICT_FLD__SYS_INDEXES__PAGE_NO），进而找到btree根page。找到根page后，通过其page header结构（见Page内部详情图左下角部分）PAGE_BTR_SEG_LEAF、PAGE_BTR_SEG_TOP两个字段可以定位出该索引的叶子和非叶子fseg；这样整个btree和fseg、extent、page的关系都建立起来了。

PAGE_BTR_SEG_TOP 和PAGE_BTR_SEG_LEAF结构

root节点的所有内部节点和所有叶子节点分别由两个fseg段组成（效率原因，分别让叶子层和内部节点的物理page集中再一起）
每个fseg内部包含很多extent（和表实际大小相关）和32个碎片page数组（来承载最初的数据512KB的数据)，每个extent1M包含64个page(16k)，为了保证访问效率，一般分配空间按段为单位，但为了减少小表空间浪费。

2. 文件空间分配 -> tree

上图中对于一个索引，会有两个fsegment段，每个对应下图标红的结构，再该索引crud的过程中，会通过其内部的FRAG_ARR来管理小数据量，通过FSET_xx来管理extent。

但是如果其FSET_FREE为空，此时就需要从全局FSP的FSP_XXX链表获取文件级别的extent空间，这部分由表头存储并通过FSP_HEADER来进行管理，见下图：

关于inode page：

由File Space Header的两个指针进行全局管理，每一项为一个inode类型的page 16KB。
每个inode page包含85个inode entry，每个inode entry对应一个file segment；
每个索引需要使用两个file segment，每个file segment对应32个琐碎page和extent链表，构成tree主体结构

索引文件布局

上面可以看到inode、file segment、extent、page等概念，其和文件物理布局之间的关系如下：

物理文件整体上按照粒度分为三类：

page：文件切分基础单位，一个page 16KB
extent：为了避免page粒度太细导致tree查找随机io问题，连续的64个page 组成一个extent，1M空间
group: 文件角度的逻辑概念，对应512个extent，实际没有使用。

关于表大小

page id为4字节，所以一个文件承载的page数为4G，容量为64TB(4GB * 16K)

文件级别当前使用空间：

通过File Space Header.Free Limit来描述当前文件有效初始化的边界。

fseg是从tree的角度引申出逻辑概念。用来管理extent。物理文件层面并没有fseg的概念，fset管理的大小可以为整个文件，最大64TB；fset和group都是逻辑概念，没有关系更没有一一对应的关系。

参考

pg表空间、innodb表空间

表空间描述不错的材料、innodb文件系统物理结构