mysql Guidelines (VI): The basic structure of the InnoDB

Foreword

In mysql Guidelines (ii): mysql logical structure and overall process flow , we see the layered structure based on the logical thought mysql, the main processing is to connect several components, the analyzer, as well as the bottom of the optimizer storage engine. System above the storage engine is to the user's request clearly understand the task, making a good plan, and then use the storage engine to complete these plans.

Therefore, the above- mentioned in the index for the study, in fact, need to learn to storage engine. With the development of Mysql, the default storage engine is InnoDB, we will learn InnoDBthis storage engine.

InnoDB we more or less have heard that he has a lot of features, there is no longer list them. In short, these features before learning principles, we also need to look at from a macro point of view of the overall structure and basic InnoDB inserted, reading process.

Benpian have to learn the basic structure of InnoDB under composition.

the whole frame

FIG overall configuration of a direct reference to the official website, as follows:

This figure is divided into two, the left side of the large solid line rectangular frame is circled memory structure, a large right rectangular frame structure is encircled on the disk. And the intermediate dashed rectangular frame identification mark Operating System Cacheis managed by the operating system itself cache component, it will be mentioned again later.

This picture looks dizzy, dizzy when we think of going to calm down, these structures actually end user perceived performance of the function. For mysql, it helps us to do the following three things:

1. Interface to store data and external exposure data processing
2. Reliability of data
3. Use of performance

After two apparently belonging to the optimization of the most basic is how the data is stored how to read, we will start with the start in this direction, so the figure can be reduced to (weed out unwanted objects):

This successfully simplifies the complexity of the structure, and now our focus is as follows:

• Memory areas
  • Buffer Pool
• Disk field
  • System Tablespace
    • Data Dictionary
  • File-Per-Table Tablespace
    • 每张表的.ibd

Tips：
关于内存访问速度和磁盘访问速度的比较：内存访问速度是磁盘顺序访问速度的好几倍；内存访问速度是 磁盘随机访问 的好几万倍。

假如硬盘访问和内存访问一样快，InnoDB 还需要这么复杂的结构吗？

所以很多情况下，InnoDB都是为了降低这两种访问速度的差异而做出不同的努力。

• 磁盘领域
  • File-Per-Table Tablespace

T1.ibd文件对应的磁盘区域中，存储了表T1的数据以及索引信息。当向T1表中写入数据时，实际上就是向这些磁盘区域写入数据。

如下图，简单理解下对应的结构。红色的01序列表示磁盘的物理存储，文件属于逻辑概念，可以理解为 T1.ibd 就是文件1，其包含文件1绿色括号对应的这些磁盘空间。而为了方便管理，又可以进一步把这些01磁盘空间划分成一个个的逻辑概念，即 页 的概念。

一个页的默认大小是 16K，而一行数据很多情况下远远小于16K，所以一个页中可以存储的行数不止一行，可能有多行。
跟磁盘进行数据交互以 页 为单位

所以，又可以认为文件1的内容对应磁盘上的 页3 和 页4。从T1中读取数据时，就是去某个页中找到该条记录并返回；当向T1中写入数据时，就是将数据追加的写到某个页中。

• 磁盘领域
  • System Tablespace

而 System Tablespace 中的 Data Dictionary 数据字典对应的磁盘区域中，就存储了其他数据表的元数据信息（metadata），比如 表 T1 有哪些字段，哪些字段上有索引等。

• 内存领域
  • Buffer Pool

如下图，InnoDB实际上管理着磁盘和内存上的数据信息。就算没有内存，也一样可以在用户查询数据时从磁盘读出后返回。

但是就像上面Tips中说的那样，InnoDB是为了减小内存和磁盘的速度差异来做设计的。所以会使用内存缓存，将访问到的 页 缓存下来。比如访问T1的第一行数据，这行数据在页1，此时将 页1 读入到内存中进行缓存；当访问T1的第4行数据时，假设该数据仍然在 页1，则可以直接在内存中查找并返回，速度大大提升。

围绕这个目标而设计出的 Buffer Pool，虽然也可以归纳到优化设计中，但是还是有必要从一开始就引入的。

再来看一下官方对于 Buffer Pool 的介绍，重点用粗体标识：

The buffer pool is an area in main memory where InnoDB caches table and index data as it is accessed. The buffer pool permits frequently used data to be processed directly from memory, which speeds up processing. On dedicated servers, up to 80% of physical memory is often assigned to the buffer pool.

也就是重要的三个信息点：

1. 缓存被访问的信息
2. 内存中访问，可以加速处理
3. 在专用服务器上，可能80%的内存空间都是留给 Buffer Pool 的，可见其有多关键

下面，我们从内存领域及磁盘领域来看看每个关键的结构部件。

磁盘领域的结构

磁盘领域设计到的东西很多，如果全部去研究只会 分散了精力，我们暂时把精力用到两件事情上：

1. 页的众多数据行是如何被组织的
2. 一个数据表下的众多页又是如何被组织的

所以，下面的描述尽可能忽略掉无关的影响参数。

页内的行组织

简化后的结构如下图：

页1中不仅包含行数据，而且还包含其他信息，只是这里我们暂不关注。页1中的各行之间类似于链表关联起来，也就是通过行1可以找到行2，通过行2可以找到行3。

每个数据行就包括行本身的参数信息，以及该行的列数据，最终这些数据实际上就是磁盘中的01二进制数据存储。

至于 InnoDB是如何把行数据转换成一定形式的二进制数据，这就是 行格式，我们暂时不提。

到这一步，关键点是要有个初步认知：

页内存储了多个数据行，可以通过遍历来知道每个数据行的数据信息

表（表空间）下的页组织

在 上文 中简单提到了索引的结构，当页数非常多的时候，如何快速定位到数据在哪一页是个重要的问题。InnoDB采取了 B+ 树的组织结构，这里我们不提为什么采用 B+ 树，等后续更加深入后相信回过头看自然就知道答案了。

这里也需要提前了解两个概念：

1. 聚簇索引：就像上图，实际上主键ID自身就带有索引，而且数据和主键索引是放在一起的，所以可以叫做聚簇索引。等真正到索引章节会再来看看的
2. 正因为有了聚簇索引这个概念，我们就可以自然的理解 索引即数据 这个称谓了。也就是我在主键这棵树中找到了主键索引，也就找到了对应的全部数据。

所以，上图中的 页4 和 页5 就是数据页，存储的实际数据。而 页14 就是索引页，存储同样是每行数据，只不过这里的每行数据由两部分构成：主键 和 数据页号 ，所以要查找 主键ID99 的数据行，就需要遍历 页14 的行记录，找到 ID99 对应的数据页的页号，这里为5，然后去页5中遍历查找数据信息，最终就找到了 ID99 的行记录。

随着数据页的增多，索引页页也变多了，那么就需要对索引页做二次索引，这样子，最终的树形结构可能就变成了下图：

假如 页1内容不需要查找已经在内存中了，那么想要读取到 ID99 的数据，还是至少要执行两次磁盘读取的，即一次读取 页14，一次读取 页4。

知道了如何组织后，我们就初步弄清楚了要研究的两个问题，暂时可以先理解到这里，后续文章还会反复回来继续细化页结构以及页内的数据如何管理，页之间如何管理的。

内存领域的结构

内存领域的结构目前我们就只需要关心 Buffer Pool 就行了。

上面已经提到了 页 这个概念，而 Buffer Pool 中最主要缓存的就是 页 数据。目的就是为了加快查找数据的速度，毕竟访问内存要快很多。同时，配合上暂时省去的其他部件，也可以加快写入的速度。

Buffer Pool 的重点在于：它处于内存中，内存远小于磁盘空间，所以必须决定页面缓存的时机，比如经常访问的页面就驻留的久一些，只访问一次的页就不要去干扰常用的页，等等这些管理页如何缓存的机制才是 Buffer Pool 的核心。

Buffer Pool 后续还会继续深入，此处了解到这里即可

小结

基于只想先了解数据是如何存储以及如何读写的缘由，对于官方的 InnoDB 结构进行简化。对简化后的各部分做了初步的介绍。

下一篇文章，我们继续来看看 页的具体结构（具体内容、具体格式）到底是什么，索引不着急，自然会出现的。