关于java:InnoDB学习一之BufferPool

28次阅读

共计 8247 个字符，预计需要花费 21 分钟才能阅读完成。

咱们晓得 InnoDB 数据库的数据是长久化在磁盘上的，而磁盘的 IO 速度很慢，如果每次数据库拜访都间接拜访磁盘，显然重大影响数据库的性能。为了晋升数据库的拜访性能，InnoDB 为数据库的数据减少了内存缓存区（BufferPool），防止每次拜访数据库都进行磁盘 IO。

<!–more–>

缓存区 BufferPool

缓存区并不是 Innodb 中特有的概念，操作系统中也有缓存区的概念，当用户第一次从磁盘读取文件时，会把文件缓存到内存中，后续再对这个文件进行读操作就能够间接从内存中读，从而缩小磁盘 IO 次数。缓存只是内存中的一块间断空间，InnoDB 是如何正当利用缓存区的空间的呢？本文会从以下几个方面介绍 InnoDB 的缓存区：

  1. 缓存区概览：InnoDB 缓存区的构造和状态查问；
  2. 缓存区实例(BufferPool Instance)：缓存区能够划分为多个实例；
  3. BufferChunk：缓存区实例内的数据块；
  4. 管制块和数据页：InnoDB 是以什么模式缓存数据库中的数据的；
  5. 闲暇空间治理；缓存区内的闲暇空间治理逻辑；
  6. 用户数据管理：数据库数据和索引在缓存区缓存的治理；
  7. 自适应哈希索引：优化热点数据等值查问的哈希索引；
  8. ChangeBuffer 简介：进步数据库更新效率的 ChangeBuffer；
  9. 锁信息管理：InnoDB 中的行锁信息也是寄存在缓存区中的；

缓存区概览

InnoDB 中的缓存区叫 innodb_buffer_pool，当读取数据时，就会先从缓存中查看是否数据的页（page）存在，不存在的话去磁盘上检索，查到后缓存到 innodb_buffer_pool 中。同理，插入、批改、删除也是先操作缓存里数据，之后再以肯定频率更新到磁盘上，这个刷盘机制叫做 Checkpoint。

如下图所示，InnoDB 中的数据次要有数据页、索引页、插入缓存、自适应哈希索引、锁信息和数据字典信息。咱们常常听到的 RedoLog 不在缓存区中。

MySQL 默认的 innodb_buffer_pool 的大小是 128M，咱们能够通过以下命令查看 innodb_buffer_pool 的参数，执行后果如下图所示：

show variables like 'innodb_buffer_pool%';

在 MySQL 应用过程中，咱们可能须要查看缓存区的状态，比方已应用空间大小、脏页大小等状态，咱们能够通过以下命令查看 innodb_buffer_pool 的状态，执行后果如下图所示，图中的执行后果中，共有 8192 页数据。

show global status like '%innodb_buffer_pool%';

缓存区实例

缓存区自身是一块内存空间，在多线程并发拜访缓存的状况下，为了保障缓存页数据的正确性，可能会对缓存区单实例锁互斥拜访，如果缓存区十分大并且多线程并发拜访十分高的状况下，单实例缓存区的可能会影响申请的处理速度。如下图所示，数据库缓存区大小为 3G，并发拜访 QPS 为 3000，如果缓存区只有一个实例，那么这 3000 个申请可能须要竞争同一个互斥锁。

MySQL 5.5 引入了缓存区实例作为减小外部锁争用来进步 MySQL 吞吐量的伎俩，用户能够通过设置 innodb_buffer_pool_instances 参数来指定 InnoDB 缓存区实例的数目，默认缓存区实例的数目为 1。缓存区实例的大小均为 `innodb_buffer_pool_size/innodb_buffer_pool_instances。如下图所示，数据库缓存区大小为 3G，并发拜访 QPS 为 3000，如果缓存区有 3 个实例，现实状况下最多每 1000 个申请会竞争同一个互斥锁。

如果缓存区总空间大小小于 1G，innodb_buffer_pool_instances会被重置为 1，因为小空间的多个缓存区实例反而会影响查问性能。

缓存区实例有以下特点：

  1. 缓存区实例有本人的锁 / 信号量 / 物理块 / 逻辑链表，缓存区实例之间没有锁竞争关系；
  2. 所有缓存区实例的空间在数据库启动时调配，数据库敞开后开释；
  3. 缓存页依照哈希函数随机散布到不同的缓存实例中；

缓存区实例的 BufferChunk

咱们晓得缓存区能够蕴含多个缓存区实例，每个缓存区实例蕴含一块间断的内存空间，InnoDB 把这块空间划分为多个 BufferChunk，BufferChunk 是 InnoDB 中的底层的物理块，BufferChunck 中蕴含数据页和管制块两局部。

BufferChunk 是最低层的物理块，在启动阶段从操作系统申请，直到数据库敞开才开释。通过遍历 chunks 能够拜访简直所有的数据页，有两种状态的数据页除外：

  1. 没有被解压的压缩页(BUF_BLOCK_ZIP_PAGE)；
  2. 批改过且解压页曾经被驱赶的压缩页(BUF_BLOCK_ZIP_DIRTY)；

BufferChunck 中蕴含数据页和管制块两局部，二者寄存的数据如下：

  1. 管制块：页面治理信息 / 互斥锁 / 页面的状态等数据块管制信息；
  2. 数据页：数据库数据 / 锁数据 / 自适应哈希数据，数据页的大小默认为 16K；

BufferChunck 数据块的大小是可配置的，MySQL 配置中默认 BufferChunck 数据块大小如下所示，用户能够在 MySQL 实例启动之前通过批改配置文件或启动参数中指定，达到自定义 BufferChunck 数据块的大小的目标。

$> mysqld --innodb-buffer-pool-chunk-size=134217728
[mysqld]
innodb_buffer_pool_chunk_size = 134217728

用户自定义 innodb_buffer_pool_chunk_size 参数的大小该当小于单个缓存区实例的空间大小。如果 innodb_buffer_pool_chunk_size 值乘以 innodb_buffer_pool_instances 大于初始化缓冲池总大小时，innodb_buffer_pool_chunk_size 则截断为 innodb_buffer_pool_size/innodb_buffer_pool_instances。

管制块和数据页

通过上文，咱们晓得 InnoDB 中的底层物理块是 BufferChunk，BufferChunk 中蕴含了管制块和数据页，本节会介绍数据页和管制块别离蕴含哪些数据。

管制块

InnoDB 中的每个数据页都有一个绝对应的管制块，用于存储数据页的治理信息，然而这些信息不须要记录到磁盘，而是依据读入数据块在内存中的状态动静生成的。查找或者批改数据页时，总是会通过管制块进行数据块操作，管制块次要蕴含以下数据：

  1. 页面治理的一般信息 / 互斥锁 / 页面的状态等；
  2. 闲暇链表 /LRU 链表 /FLU 链表等链表的治理；
  3. 依照肯定的哈希函数疾速定位数据页地位；

数据页

InnoDB 中，数据管理的最小单位为页，默认是 16KB，页中除了存储用户数据，还能够存储管制信息的数据。InnoDB IO 子系统的读写最小单位也是页。如果对表进行了压缩，则对应的数据页称为压缩页，如果须要从压缩页中读取数据，则压缩页须要先解压，造成解压页，解压页为 16KB。压缩页的大小是在建表的时候指定，目前反对 16K，8K，4K，2K，1K。即便压缩页大小设为 16K，在 blob/varchar/text 的类型中也有肯定益处。假如指定的压缩页大小为 4K，如果有个数据页无奈被压缩到 4K 以下，则须要做 B -tree 决裂操作，这是一个比拟耗时的操作。

数据页能够用于寄存以下类型的数据，下文中咱们会对这些类型的数据结构进行具体介绍：

  • 用户数据，聚簇索引和非聚簇索引对应的节点数据；
  • 行锁信息，InnoDB 锁过多异样时，能够通过减少 BufferPool 大小解决；
  • 自适应哈希，用于缓存热点数据；
  • ChangeBuffer 缓存；

闲暇空间治理

当咱们最后启动服务器的时候，须要实现对的初始化过程，就是调配的内存空间，把它划分成若干对管制块和缓存页。然而此时并没有实在的磁盘页被缓存到中（因为还没有用到），之后随着程序的运行，会一直的有磁盘上的页被缓存到中，那么问题来了，从磁盘上读取一个页到中的时候该放到哪个缓存页的地位呢？或者说怎么辨别中哪些缓存页是闲暇的，哪些曾经被应用了呢？咱们最好在某个中央记录一下哪些页是可用的，咱们能够把所有闲暇的页包装成一个节点组成一个双向链表，这个链表也能够被称作（或者说闲暇链表）。

如果 InnoDB 刚刚启动，缓存区的所有缓存页都是闲暇的，每一个缓存页都会被退出到闲暇链表中，此时闲暇列表的构造如下所示（此处省略数据页，闲暇链表的指针指向数据块的管制块）。

在须要加载缓存页到 BufferPool 的状况下，如果闲暇链表不为空，咱们能够从闲暇链表中获取一页闲暇数据页，将缓存放入闲暇的数据页。以 LRU（后文具体介绍）为例，InnoDB 启动后，LRU 加载第一个缓存页之后，BufferPool 中的数据状况如下所示。

用户数据管理

用户数据管理是 BufferPool 中最重要的数据，蕴含表数据与索引数据等数据，用户数据会依照数据的状态进行治理，次要蕴含以下数据管理，下文会一一介绍这几种链表：

  1. 最近起码应用链表(Least Recently Used, LRU)：InnoDB 中最重要的链表，蕴含所有读取进来的数据页；
  2. 脏页链表(Flush LRU List)：治理 LRU 中的脏页，后盾线程定时写入磁盘；
  3. 解压页链表(Unzip LRU List)：治理 LRU 中的解压页数据，解压页数据是从压缩页通过解压而来的；
  4. 压缩页链表(Zip List)：顾名思义，对页数据压缩后组成的链表；

最近起码应用链表 LRU

最近起码应用链表 LRU 用于缓存表数据与索引数据，因为内存大小通常远远小于磁盘大小，内存中无奈缓存全副的数据库数据，所以缓存通常须要肯定的淘汰策略，淘汰缓存中不常常应用的数据页。InnoDB 的 BufferPool 采纳了改进版的 LRU 的淘汰策略。

如下图所示，LRU 链表的构造和闲暇链表的构造相似，是一个双向链表，链表中的节点蕴含指向数据页管制块的指针，能够通过管制块拜访数据页中的数据。

当须要将新数据页增加到缓冲池时，最近起码应用的数据页会可能会从 LRU 链表中淘汰，并将新数据页增加到 LRU 链表的两头。此插入点将列 LRU 链表划分为两个子链表：

  1. 头部的 5 / 8 区域，最近拜访多的热数据列表；
  2. 尾部的 3 / 8 区域，最近拜访少的冷数据列表；

LRU 算法会将常常应用的数据页保留在热数据列表中，冷数据列表中蕴含了不常常拜访的数据页，这些数据页是 LRU 列表满了之后最先被淘汰的数据。默认状况下，算法的流程如下：

  1. LRU 链表的的后 3 / 8 区域用于存储冷数据；
  2. LRU 链表的中点是热数据尾部与冷数据头部相交的边界；
  3. 被拜访的冷数据会从冷数据链表挪动到热数据链表；
  4. 热数据链表中的数据如果长时间不拜访，会逐步移入冷数据链表；
  5. 冷数据长时间不被拜访，并且 LRU 链表满了，那么开端的冷数据会淘汰出 LRU 链表；
  6. 预读的数据只会插入 LRU 链表，不会被挪动到热数据链表；

LRU 算法还有一个问题，当某一个 SQL 语句，要批量扫描大量数据时，因为这些页都会被拜访，可能导致把缓冲池的所有页都替换进来，导致大量热数据被换出，MySQL 性能急剧下降，这种状况叫缓冲池净化。MySQL 缓冲池退出了一个 冷数据停留时间窗口 的机制：

  1. 假如 T = 冷数据停留时间窗口；
  2. 插入冷数据头部的数据页，即便立即被拜访，也不会立即放入新生代头部；
  3. 只有满足 被拜访 并且 在冷数据区域停留时间 大于 T，才会被放入新生代头部；

退出 冷数据停留时间窗口 策略后，短时间内被大量加载的页，并不会立即插入新生代头部，而是优先淘汰那些短期内仅仅拜访了一次的页。

MySQL 中 LRU 链表相干的参数:

  • innodb_old_blocks_pct：冷数据占整个 LRU 链长度的比例，默认是 3 /8，即整个 LRU 中热数据与冷数据长度比例是 5:3。
  • innodb_old_blocks_time：冷数据停留时间窗口 机制中冷数据停留时长；

脏数据链表 FLU

当须要更新一个数据页时，如果数据页在内存中就间接更新更新内存中的数据，然而因为写回磁盘的代价比拟高，所以 InnoDB 并不会立即把批改后的数据写回磁盘，此时，就呈现了缓存区数据页和磁盘数据页中的数据不统一的状况，这种状况下缓存区数据页被称为脏页，治理所有脏页的链表叫脏数据链表，以下为脏数据链表的示例图：

脏数据链表是 LRU 链表的子集，LRU 链表蕴含了所有的脏页数据。脏页中的数据最终是要写回磁盘的，将内存数据页刷到磁盘的操作称为 刷脏 ，以下是几种会触发 InnoDB 刷脏 的状况

  • InnoDB 的 RedoLog 写满了，这时候零碎会进行所有更新操作，把 Checkpoint 往前推动，RedoLog 留出空间能够持续写；
  • 当零碎内存不足，须要把一个脏页要从 LRU 链表中淘汰时，要先把脏页写回磁盘；
  • MySQL 在闲暇时，会主动把一部分脏页写回磁盘；
  • MySQL 失常敞开时，会把所有脏页都写回磁盘；

InnoDB 中能够通过一些参数设置刷脏行为：

  • innodb_io_capacity：MySQL 数据文件所在磁盘的 IO 能力，innodb_io_capacity参数会影响 MySQL 刷脏页的速度。磁盘的 IOPS 能够通过 FIO 工具来测试，测试命令如下所示：

    fio -filename=$filename -direct=1 -iodepth 1 -thread -rw=randrw -ioengine=psync -bs=16k -size=500M -numjobs=10 -runtime=10 -group_reporting -name=mytest

    如果不能正确地设置 innodb_io_capacity 参数，可能能导致数据库性能问题。举个例子阐明：如果 MySQL 主机磁盘用的是 SSD，然而 innodb_io_capacity 的值设置的是比拟低，只有 300。这种状况下，InnoDB 认为这个零碎的 IO 能力只有 300，所以刷脏页刷得特地慢，甚至比脏页生成的速度还慢，这样就造成了脏页累积，影响了查问和更新性能。

  • innodb_flush_neighbors：在筹备刷一个脏页的时候，如果这个数据页旁边的数据页刚好是脏页，就会把这个“街坊”也带着一起刷掉；而且这个把“街坊”拖下水的逻辑还能够持续蔓延，也就是对于每个街坊数据页，如果跟它相邻的数据页也还是脏页的话，也会被放到一起刷。innodb_flush_neighbors参数就是用来管制这个行为的，值为 1 的时候会有上述的“连坐”机制，值为 0 时示意不找街坊，本人刷本人的。对于 SSD 这类 IOPS 比拟高的设施，IOPS 往往不是瓶颈，innodb_flush_neighbors应该设置为 0。在 MySQL8.0 中，innodb_flush_neighbors参数的默认值曾经是 0 了。
  • innodb_max_dirty_pages_pct：脏页比例超过 innodb_max_dirty_pages_pct 之后，InnoDB 会全力刷脏页，如果没超过这个比例，那么刷脏页速度 =max(以后脏页比例 /innodb_max_dirty_pages_pct*innodb_io_capacity, RedoLog 的缓存大小计算刷脏页速度)；

压缩页链表(Zip List)

Mysql 容许用户对表进行压缩以节俭磁盘空间，这些压缩页的数据在进入内存之后，要进行解压之后能力应用。

咱们能够通过以下 SQL 语句建设一张 InnoDB 数据表：

create table user_info
(
    id   int primary key,
    age  int not null,
    name varchar(16),
    sex  bool
)engine=InnoDB;

对于建设好的 InnoDB 数据表，咱们能够通过以下 SQL 语句对表进行压缩，压缩后表占用的磁盘空间会减小：

alter table user_info row_format=compressed;

InnoDB 中的表压缩是针对表数据页的压缩，不仅能够压缩表数据，还能够压缩表索引。压缩页的大小能够是 1k/2k/4k/8k。

压缩页链表存储的就是这些压缩后的页，压缩页在加载进内存之后，并不会立刻解压，而是在须要应用的时候再进行解压。

压缩页有不同的大小 1k/2k/4k/8k，InnoDB 应用了搭档治理算法来治理压缩页。有 5 个 ZipFree 链表别离治理 1k/2k/4k/8k/16K 的内存碎片，8K 的链表里存储的都是 8K 的碎片，如果新读入一个 8K 的页面，首先从这个链表中查找，如果有则间接返回，如果没有则从 16K 的链表中决裂出两个 8K 的块，一个被应用，另外一个放入 8K 链表中。

解压页链表(Unzip LRU List)

压缩页链表中的数据都是被压缩的，不能间接 CRUD，应用前须要解压，解压后的数据都存储在解压页链表中，解压页链表中的数据写回磁盘时须要压缩。

自适应哈希索引

咱们晓得 B + 树默认的索引数据结构是 B + 树，B+ 树对范畴查问或者 LIKE 语法的反对比拟好。

如果数据库中有大量的等值查问，应用哈希索引能显著晋升查问效率。Innodb 存储引擎会监控对表上二级索引的查找，如果发现某二级索引被频繁拜访，二级索引成为热数据，会对该热点数据建设内存哈希索引，这个索引被称为自适应哈希索引。

自适应哈希索引默认是开启状态，能够通过设置 innodb_adaptive_hash_index 变量或在启动 MySQL 时增加 --skip-innodb-adaptive-hash-index 变量启用自适应哈希索引。

InnoDB 中能够查看到哈希索引的应用状况，命令及输入如下所示：

mysql> show engine innodb status\G
……
Hash table size 34673, node heap has 0 buffer(s)
0.00 hash searches/s, 0.00 non-hash searches/s

ChangeBuffer

在批改数据库数据时，如果对应的数据页刚刚好在缓存区，能够之间批改缓存区的数据页，并把数据页标记为脏页。

如果批改数据数据时，对应的数据页如果不在缓存区，就须要把数据页从磁盘加载到缓存区，而后进行批改。对于写多读少的场景，会产生大量的磁盘 IO，影响数据库的性能。

Change Buffer 对数据更新过程有减速作用。如果数据页没有在内存中，会将更新操作缓存到 Change Buffer 中，这样就不须要从磁盘读入这个数据页，缩小了 IO 操作，进步了性能。先将更新操作，记录在 Change Buffer 中，之后再进行 merge, 真正进行数据更新。InnoDB Change Buffer 比较复杂，我会在后续独自章节中进行介绍。

行锁信息管理

InnoDB 反对行锁，能够对数据库中的数据进行加锁操作，这些锁信息也寄存在 BufferPool 中，具体存储格局此处不做具体解释。

既然锁信息都寄存在 BufferPool 中，那么锁的数目必定受缓存区大小的影响，如果 InnoDB 中锁占据的空间超过了 BufferPool 总大小的 70%，在新增加锁时会报以下谬误：

[FATAL] InnoDB: Over 95 percent of the buffer pool is occupied by lock heaps or the adaptive hash index! Check that your transactions do not set too many row locks. Your buffer pool size is 8 MB. Maybe you should make the buffer pool bigger? We intentionally generate a seg fault to print a stack trace on Linux!For more information, see Help and Support Center at http://www.mysql.com.

我是御狐神，欢送大家关注我的微信公众号:wzm2zsd

参考文档

  1. MySQL 8.0 Reference Manual/The InnoDB Storage Engine/InnoDB Architecture
  2. Chunk Change: InnoDB Buffer Pool Resizing
  3. 玩转 MySQL 之十 InnoDB Buffer Pool 详解
  4. InnoDB 的 Buffer Pool 简介
  5. Mysql 的 Innodb 存储引擎缓冲池集体了解
  6. InnoDB 要害个性之自适应 hash 索引
  7. InnoDB 页压缩技术

本文最先公布至微信公众号，版权所有，禁止转载！

正文完
java
发表至： java
2021-12-07
 0
乐字节Java反射之四反射相关操作
关于java:记一次ThreadLocal引发的线上故障年终奖没了可能还面临辞退
关于java:Mybatis自动生成增删改查代码
dubbo源码解析（三十）远程调用——rest协议