Mysql 专栏 – 缓冲池补充、数据页、表空间简述

前言

​ 这一节咱们来持续讲述对于缓冲池的内容，以及对于数据页和表空间的内容，当然内容页比拟根底和简略，了解相干概念即可。

概述

1. 补充缓冲池的内容，对于后盾刷新线程，以及多线程拜访 buffer pool 的锁模式等
2. 数据行和数据页的构造，简要的理解简略的外部细节。
3. 表空间以及数据区，以及整个 mysql 表的逻辑构造

缓冲池补充

​ 在介绍具体的内容之前，这里先补充对于缓冲池的一些细节。

后盾线程定时刷新冷数据

​ 上一节提到了冷热数据拆散，其实冷数据不可能是在缓冲池满的时候才会进行刷新的，而是会在 LRU 冷数据的尾部随机找几个缓存页刷入磁盘，他会有一个定时工作，每隔一段时间就进行刷新的操作，同时将刷新到磁盘之后的数据页退出到 free 链表当中。所以 LRU 的链表会定期把数据刷入到磁盘当中进行解决，并且在缓存没有用完的时候会清空一些无用的缓存页。

flush 链表的数据定期刷入缓存

​ flush 的链表寄存的是脏页数据，当然它也有一个定时工作，会定期把 flash 链表的数据刷入到缓冲池当中，并且咱们也能够大抵认为整个 LRU 是一直的挪动的，flush 链表的缓存页页在一直的缩小，free list 的内容在一直变多。

多线程并发拜访是否会加锁

​ 多线程拜访的时候会进行加锁，因为读取一个缓冲页波及 free list, flush list, lru list 三个链表的操作，并且还须要对于数据页进行哈希函数的查找操作，所以整个操作过程是必定要加锁的，尽管看似操作的链表有三个，然而实际上消耗不了多少的性能，因为链表的操作都是一些指针的操作查找操作，所以根本都是一些常数的工夫和空间耗费，即便是排队来一个个解决，也是没有多大的影响的。

多个 buffer pool 并行优化

​ 当 mysql 的 buffer pool 大于 1g 的 时候其实能够配置多个缓冲池，MySQL 默认的规定是：如果你给 Buffer Pool 调配的内存小于 1GB，那么最多就只会给你一个 Buffer Pool。比方在上面的案例当中如果是一个 8G 的 Mysql 服务器，能够做如下的配置：

[server]
innodb_buffer_pool_size = 8589934592
innodb_buffer_pool_instances = 4

​ 这样就能够设置 4 个 buffer pool，每一个占用 2g 大小。理论生产环境应用 buffer pool 进行调优是非常重要的。

运行过程中能够调整 buffer pool 大小么？

​ 就目前解说来看，是无奈实现动静的运行期间调整大小的。为什么？因为如果要调整的话须要把整个缓冲区的大小拷贝到新的内存，这个速度切实是太慢了。所以针对这一个问题，mysql 引入了 chunk 的概念。

mysql 的 chunk 机制把 buffer pool 拆小

​ 为了实现动静的 buffer pool 扩大，buffer pool 是由很多 chunk 组成的，他的大小是 innodb_buffer_pool_chunk_size 参数管制的，默认值就是 128MB，也就是说一个 chunk 就是一个默认的缓冲池的大小，同时缓存页和形容信息也是依照 chunk 进行分块的，假如有一个 2G 的 chunk 的，它的每一个块是 128M，也就是大略有 16 个 chunk 进行切割。

​ 有了 chunk 之后，申请新的内存空间的时候，咱们要把之前的缓存复制到新的空间就好办了，间接生成新的到 chunk 即可。而后把数据搬移到新的 chunk 即可。

生产环境给多少 buffer pool 适合？

​ 如果 32g 的 mysql 机器要给 30g 的 buffer pool，想想也没有情理！crud 的操作根本都是内存的操作，所以性能非常高，对于 32g 的内存，你的机器起码就得用好几个 g 的解决，所以首先咱们能够调配一半的内存给 mysql. 或者给个 60% 左右的内容即可。

 `innodb_buffer_pool_size` 默认的状况下为 128M，最大值取决于 CPU 的架构。在 32-bit 平台上，最大值为 `(2^32 -1)`, 在 64-bit 平台上最大值为 `(2^64-1)`。当 ** 缓冲池大小大于 1G 时 **，将 `innodb_buffer_pool_instances` 设置大于 1 的值能够进步服务器的可扩展性。最初大的缓冲池能够减小屡次磁盘 I / O 拜访雷同的表数据，如果数据库配置在专门的服务器当中，能够将缓冲池大小设置为服务器物理内存的 60 - 80%，也就是说 32g 的内容给 24g - 26g 都是比拟好的抉择，当然。

buffer pool 调配公式：

​ 对于 buffer pool，这里有一个要害的公式：buffer pool 总大小 =(chunk 大小 * buffer pool 实例数量)的倍数 ，默认的 chunk 大小是 128M, 要给 20G 的 buffer pool，而后依照公式套入就是：Buffer pool = 128 * 16 * 10，也就是每一个 chunk 大小是 128，再次强调一遍buffer pool 总大小 =(chunk 大小 * buffer pool 数量) 的倍数

缓冲池的配置有如下的规定：

• 缓冲池大小必须始终等于或者是 innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances 的倍数（innodb_buffer_pool_instances 指的就是实例的数量）。
• 如果将缓冲池大小更改为不等于或等于 innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances 的倍数的值，则缓冲池大小将主动调整为等于或者是 innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances 的倍数的值。

查看线上状况

​ 当你的数据库启动之后，执行 SHOW ENGINE INNODB STATUS 就能够了。此时你可能会看到如下一系列的货色:

Total memory allocated xxxx; Dictionary memory allocated xxx Buffer pool size xxxx Free buffers xxx
Database pages xxx
Old database pages xxxx
Modified db pages xx
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young xxxx, not young xxx
xx youngs/s, xx non-youngs/s
Pages read xxxx, created xxx, written xxx
xx reads/s, xx creates/s, 1xx writes/s
Buffer pool hit rate xxx / 1000, young-making rate xxx / 1000 not xx / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s LRU len: xxxx, unzip_LRU len: xxx
I/O sum[xxx]:cur[xx], unzip sum[16xx:cur[0]

​ 上面咱们给大家解释一下这里的货色，次要解说这里跟 buffer pool 相干的一些货色。

​ 相干解释：

(1)Total memory allocated，这就是说 buffer pool 最终的总大小是多少
(2)Buffer pool size，这就是说 buffer pool 一共能包容多少个缓存页
(3)Free buffers，这就是说 free 链表中一共有多少个闲暇的缓存页是可用的
(4)Database pages 和 Old database pages，就是说 LRU 链表中一共有多少个缓存页，以及冷数据区域里的缓存页 数量
(5)Modified db pages，这就是 flush 链表中的缓存页数量
(6)Pending reads 和 Pending writes，期待从磁盘上加载进缓存页的数量，还有就是行将从 LRU 链表中刷入磁盘的数 量、行将从 flush 链表中刷入磁盘的数量
(7)Pages made young 和 not young，这就是说曾经 LRU 冷数据区域里拜访之后转移到热数据区域的缓存页的数 量，以及在 LRU 冷数据区域里 1s 内被拜访了没进入热数据区域的缓存页的数量
(8)youngs/ s 和 not youngs/s，这就是说每秒从冷数据区域进入热数据区域的缓存页的数量，以及每秒在冷数据区 域里被拜访了然而不能进入热数据区域的缓存页的数量
(9)Pages read xxxx, created xxx, written xxx，xx reads/s, xx creates/s, 1xx writes/s，这里就是说曾经读取、创立和写入了多少个缓存页，以及每秒钟读取、创立和写入的缓存页数量
(10)Buffer pool hit rate xxx / 1000，这就是说每 1000 次访问，有多少次是间接命中了 buffer pool 里的缓存的 (11)young-making rate xxx / 1000 not xx / 1000，每 1000 次访问，有多少次访问让缓存页从冷数据区域挪动到 了热数据区域，以及没挪动的缓存页数量
(12)LRU len: 这就是 LRU 链表里的缓存页的数量 (13)I/O sum: 最近 50s 读取磁盘页的总数 (14)I/O cur: 当初正在读取磁盘页的数量

数据行和数据页的构造

​ 在理解这些概念之前，咱们须要先理解上面这些问题：

为什么 mysql 不能间接更新磁盘?

​ 因为一个申请间接对于磁盘文件读写，尽管技术上没问题，然而性能会极差。磁盘的读写性能十分的差，所以不可能更新磁盘文件读取磁盘的。

为什么要引入数据页的概念?

​ 一个数据必定不是加载一条就读取一次磁盘文件的，就好比你烧柴不可能每次只拿一根，烧完再去拿一根，个别都是间接拿一捆柴拿而后拿到了一个个丢进去，这样就快了，数据页也是如此，之前说过一个数据页占 16kb，所以必定是加载很多行到数据页的外部。

数据行

数据行在磁盘外面怎么放?

​ 之前都是探讨数据怎么在缓存页放，当初咱们回过头来看下数据行在数据页外面要怎么放。这里其实波及一个叫做 行格局 的概念 ， 一个表能够指定一个行是以什么样的格局进行存储，比方上面的形式指定行格局：

CREATE TABLE customer (name VARCHAR(10) NOT NULL, address VARCHAR(20),
gender CHAR(1),
job VARCHAR(30),
school VARCHAR(50)
) ROW_FORMAT=COMPACT;

​ 对于行的存储格局，在 mysql 当中是如下存储的：

变长字段的长度列表，null 值列表，数据头，column01 的值，column02 的值，column0n 的值 ……

​

变长数据是如何寄存的？

​ 依据下面的行格局定义，置信也能够猜出来一部分，假如咱们有一个字段是 varchar（5）内容是 abcd, 有一个字段是 varchar(10)内容是 bcd，实际上存储则是依照上面这种格局存储，然而如果你是 char(1)则不须要额定的一个变长字段长度的参数，间接放到对应的字段外面即可：

​ 须要留神的是这里的变长长度参数是逆序存储的，是 逆序存储 的。

为什么一行数据的 null 不能间接存储？

​ null 值是以二进制的形式进行存储的，并且变长参数的字段实际上只存储有值的数据，如果数据是没有值为一个 null 也不须要存储变长字段的长度参数。null 值依照 bit 位存储的，并且在对应的 null “ 坑位 ” 放一个 1 或者 0， 1 示意是 null，0 示意不是 null。

​ 举个例子，4 个字段外面 2 个为 null，2 个不是则是 1010，然而理论存储的时候也是 逆序的，也是逆序的是 0101

​ 另外存储的时候不是 4 个 bit 地位，而是应用 8 个 bit 的倍数（8 的倍数，有点像 java 的对象头的补充数据位的操作.），如果有余 8 个则须要补 0，所以最初的后果如下：

0x09 0x04 00000101 头信息 column1=value1 column2=value2 … columnN=valueN，

那要如何存储？

​ 其实就依照紧凑的形式存储成为一行的数据，这样紧凑的形式不仅能够节俭空间，并且能够使得操作内存成为一种相似数组的程序拜访的操作。

40 个 bit 位的数据头：(索引的时候才解读，伞兵，掠过)

​ 在下面的结构图中，每一行数据的存储还须要一个 40 位的 bit 数据头，并且用来形容这个数据，这里咱们先简略理解数据头的构造，在后续的内容会再次进行解释：

• 首先 1 和 2 都是预留，第一个 bit 位和第二个都是预留的地位，没有任何的含意。
• 用一个 bit 位的 delete_mask 来标记这个行是否曾经被删除了(第三位)。所以其实不论你怎么设计其实 mysql 外部的删除都是一个假删除
• 下一个 bit 地位应用 1 位min_rec_mask(第四位)，b+ 树当中的每一层的非叶子节点的最小值的标记
• 下一个 bit 地位为 4 个bitn_owned（第五位），具体的作用临时不进行介绍。
• 下一个为 13 个 bit 位的heap_no，记录在堆里的地位，对于堆也会放到索引外面介绍。
• 下一个是 3bit 的record_type 行数据类型：0 一般类型，1b+ 树的叶子节点，2 最小值数据，3 最大值数据
• 最初是 16 个 bit 的next_record，这个是指向下一条数据的指针

每一行数据实在的物理存储构造：

​ 在实在的磁盘文件中，存储的内容还有不同，那就是对于数据的内容，下面咱们介绍了如何存储一行数据。

0x09 0x04 00000101 0000000000000000000010000000000000011001 jack m xx_school

​ 然而实际上稍微有些差异，在理论的磁盘存储的过程是依照 字符集编码 进行存储的，一行数据实际上上面这样滴：

0x09 0x04 00000101 0000000000000000000010000000000000011001 616161 636320 6262626262

 这种存储构造其实也能够说不管你的字段类型如何定义，到最初都是字符串。

数据库实在存储的暗藏字段

​ mysql 在数据行外面减少了一些暗藏的字段，一方面是为了实现 MVCC，另一方面是为了实现事务的须要。

• DB_ROW_ID：行惟一标识，不是主键 id 的字段，如果没有制订主键和 unique key，就会外部退出一个 ROW_ID
• DB_TRX_ID：和事务无关的一个，那个事务更新这是事务的 ID
• DB_ROLL_PTR：这是一个回滚指针，进行事务回滚的

行溢出了怎么办?

​ 有时候咱们定义的数据行数据量过大的时候，会呈现一个数据页无奈存储数据行的状况，mysql 这里又应用了链表的的形式把多个数据页串联在一起，他个结构图如下所示：

​ 从图中能够看出当数据溢出的时候，一个数据页会通过一个相似链表指针的形式指向下一个数据页的节点，通过链表的模式把许多个数据页串联在一起。

​ 至此咱们能够做一点总结，当咱们在数据库里插入一行数据的时候，实际上是在内存里插入一个有简单存储构造的一行数据，而后随着一些条件的产生，这行数据会被刷到磁盘文件里去。

数据页

最小单位是数据页

​ 数据库的最小单位是数据页，然而数据页里不都是一行一行的数据么，其实一个数据页蕴含了上面的局部：文件头，数据页头，最大最小记录，多个数据行和闲暇区域，最初是数据页目录和文件尾部，这里为了更好的察看构造，我把图横过去了：

大小占比

​ 文件头 38 个字节，数据页头站了 56 个字节，最大和最小记录占了 26 个字节，数据行区域和闲暇区域的大小是不固定的，数据页的目录也是不固定的，文件结尾占 8 位。（我擦，怎么多出这么多概念，这是啥货色，其实就是 mysql 设计的一种非凡的存储格局，了解即可）

​ 通过这种形式存放数据页，每一个数据页蕴含了很多数据行，每一个数据行就是用下面提到的形式进行存储的，数据页最开始的时候是空的。

当呈现很多个数据页的时候，能够看到如下的内容，更新缓存页的时候，LRU 链表会一直的交替挪动冷数据和热数据，通过 LRU 和 flush 把脏页刷到磁盘。

表空间和数据区的概念

​ 其实咱们平时创立的表是存在 表空间和数据区 的概念的

表空间

​ 从 InnoDB 逻辑存储构造来看，所有的数据都被逻辑的寄存在一个空间中，这个空间就叫做表空间（tablespace）。表空间由 段（segment）、区（extent）、页（page）组成。

​ 当咱们创立一个表之后，在磁盘上会有对应的表名称 .ibd 的磁盘文件。表空间的磁盘文件外面有很多的数据页，一个数据页最多 16kb，因为不可能一个数据页一个磁盘文件，所以数据区的概念引入了。

​ 一个数据区对应 64 个数据页，就是 16kb，一个数据区是 1mb，256 个数据区被划分为一组，对于表空间而言，他的第一组数据区的第一个数据区的前 3 个数据页，都是固定的，外面寄存了一些描述性的数据。比 如 FSP_HDR 这个数据页，他外面就寄存了表空间和这一组数据区的一些属性。IBUF_BITMAP 数据页，寄存的就是 insert buffer 的信息，INODE 数据页寄存的也是非凡信息。

 再次强调一遍：咱们平时创立的那些表都是有对 应的表空间的，每个表空间就是对应了磁盘上的数据文件，在表空间里有很多组数据区，一组数据区是 256 个数据区，每个数据区蕴含了 64 个数据页，是 1mb    

段（segment）

​ 段 (Segment) 分为索引段，数据段，回滚段等。其中索引段就是非叶子结点局部，而数据段就是叶子结点局部，回滚段用于数据的回滚和多版本控制。一个段蕴含 256 个区(256M 大小)。

​ 一个段蕴含多少区：256 个区

区（extent）

​ 区是页的汇合，一个区蕴含 64 个间断的页，默认大小为 1MB (64*16K)。

页（page）

​ 页是 InnoDB 治理的最小单位，常见的有 FSP_HDR，INODE, INDEX 等类型。所有页的构造都是一样的，分为文件头(前 38 字节)，页数据和文件尾(后 8 字节)。页数据依据页的类型不同而不一样。

​ 每个空间都分为多个页，通常每页 16 KiB。空间中的每个页面都调配有一个 32 位整数页码，通常称为“偏移量”（offset），它实际上只是页面与空间结尾的偏移量（对于多文件空间，不肯定是文件的偏移量）。因而，页面 0 位于文件偏移量 0，页面 1 位于文件偏移量 16384，依此类推。（InnoDB 的数据限度为 64TiB，这实际上是每个空间的限度，这次要是因为页码是 32 位整数与默认页大小的组合

最初能够用上面的图来示意具体内容：

总结

​ 本节咱们持续补充了 buffer pool 的细节，同时理解了额数据行和数据页在磁盘上的存储构造，最初咱们简略理解了一个表的逻辑存储接构造，次要的内容是表空间，数据区和数据页。至此，置信大家对于整个 mysql 的根底物理和逻辑构造有了一个大抵的理解。

写在最初

​ 本文篇幅稍长，感激急躁观看，集体程度无限，如果有谬误或者意见欢送指导。

思考题：

为什么 mysql 要这样存放数据，为什么要让他们紧紧的挨在一起进行存储？

 其实认真想想不难给出答案，次要蕴含上面几个起因：

1. 尽可能存储更多的内容：紧凑意味着着能够存储更多的数据和内容，也能够保障缓冲池的空间利用率
2. 便于程序读写：磁盘的程序读写的速度在某种程度上能够匹敌内存，所以用这种格局存储是有利于 io 操作的

为什么 null 列表要依照 bit 位的操作进行存储？

最初的数据样子如下：

0x09 0x04 00000101 0000000000000000000010000000000000011001 00000000094C(DB_ROW_ID) 00000000032D(DB_TRX_ID) EA000010078E(DB_ROL_PTR) 616161 636320 6262626262

​ 如果你在执行 CRUD 的时候要从磁盘加载数据页到 Buffer Pool 的缓存 页的时候，一旦此时没有闲暇的缓存页，就必须从 LRU 链表的冷数据区域的尾部把一个缓存页刷入磁盘，而后腾出来 一个闲暇的缓存页，接着你能力基于缓存数据来执行这个 CRUD 的操作。然而如果频繁的呈现这样的一个状况，那你的很多 CRUD 执行的时候，难道都要先刷一个缓存页到磁盘下来? 而后再从 磁盘上读取一个数据页到闲暇的缓存页里来? 这样岂不是每次 CRUD 操作都要执行两次磁盘 IO? 那么性能岂不是会极差?

​ 所以咱们来思考一个问题: 你的 MySQL 的内核参数，应该如何优化，优化哪些地方的行为，才可能尽可能的防止在执 行 CRUD 的时候，常常要先刷一个缓存页到磁盘下来，能力读取一个磁盘上的数据页到闲暇缓存页里来?

其实联合咱们理解到的 buffer pool 的运行原理就能够晓得，如果要防止上述问题，说白了就是防止缓存页频繁的被应用结束。那么咱们晓得实际上你在应用缓存页的过程中，有一个后盾线程会定时把 LRU 链表冷数据区域的一些缓存页 刷入磁盘中。所以实质上缓存页一边会被你应用，一边会被后盾线程定时的开释掉一批。

如何读取一个数据页的？

​ 读取一个数据页的伪代码如下：

dataFile.setStartPosition(25347) 
dataFile.setEndPosition(28890) 
dataFile.write(cachePage)

​ 在伪代码外面读取一个数据页首先须要的是开始和完结的工夫位，通过表空间找到对应的段，而后找到对应的数据区，依据分区找到对应的数据页，而后页的外部数据行如下的形式进行展现：

​ 因为一个数据页的大小其实是固定的，所以一个数据页固定就是可能在一个磁盘文件里占据了某个开始地位到完结地位的一段数据，此时你写回去的时候也是一样的，抉择好固定的一段地位的数据，间接把缓存页的数据写回去，就笼罩掉了原来的那个数据页了，就如下面的伪代码示意