InnoDB 引擎三大特性

绝地灬酷狼 2022-10-14 10:57 281阅读 0赞

### InnoDB 引擎三大特性 ###

*  双写缓冲区（DoubleWrite Buffer）
 *   *  原理
     *  为什么要用双写缓冲区？
 *  AHI 自适应哈希
 *  Buffer Pool
 *   *  什么是 Buffer Pool？
     *  Buffer Pool 内部组成
     *  Buffer Pool 中的链表结构
     *   *  Free 链表
         *  Flush 链
         *  LRU 链表
     *  MySQL 刷新数据落盘的途径
 *  InnoDB 的内存结构总结

# 双写缓冲区（DoubleWrite Buffer） #

## 原理 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70]

双写缓冲区是 InnoDB 引擎为了保证数据安全性，完整性而开发的

双写缓冲区是在系统表空间中

InnoDB 引擎会在磁盘上划分出连续的两个区的范围

1个区包含64个页，一个页 16k，1个区 = 64x16 = 1024k = 1M

因此一个双写缓冲区大小为两个 1M ，共 2M

当我们写数据时，InnoDB 会先把数据从内存的双写缓冲区中，接着调用 fsync 写入到磁盘的双写缓冲区上（完整页数据），最后再把数据写入对应数据页中。

如果在写页的过程中发生意外崩溃，InnoDB 在稍后的恢复过程中在双写缓冲区中找到完好的 page 副本用于恢复。

## 为什么要用双写缓冲区？ ##

**问题：双写缓冲区要写磁盘，数据之后也是要写磁盘，为什么还要提前写个双写缓冲区？这样不是增加IO？**

答：首先一页数据是 16 kb，磁盘写一次是 4kb，因此一页数据写磁盘，要写 4 次。  
假如在写的过程中假如写了 8kb 数据库崩了，就会导致部分页写入问题，页的数据不完整，数据就会有问题。而双写缓冲区作为一块预分配的磁盘位置，数据库在写磁盘双写缓冲区时是使用的顺序写，因此效率上要比直接写数据的随机写快的多，出问题的概率小。

**问题：fsync 是什么？**

答：fsync 是底层操作系统对外提供的一个 API 接口，他能保证数据必然已经落盘。

**问题：假如数据库突然挂了，双写缓冲区是如何恢复数据的？**

答：双写缓冲区存在的目的就是 Innodb 为了保证 MySQL 数据的原子性。假如数据库数据写一半挂了，那么 MySQL 启动时，会从磁盘的双写缓冲区中找到直接写入的完整的数据副本，再用这个完整的副本去对有问题的页数据进行恢复。

**问题：假如写双写缓冲区挂了呢？**

答：既然 MySQL 的双写缓冲区是双写机制，第一步写到磁盘的双写缓冲区自然有可能失败。假如失败了，MySQL 会根据磁盘上 B+ 树的结构，再配合上 Redo 日志对数据进行恢复。

**问题：既然可以通过 Redo 日志进行恢复，那么为什么还要双写缓冲区？**

答：MySQL 的 Redo 日志存储的是对页的物理操作，也就是修改部分的操作，非修改部分的数据不保存。也就说假如我修改了 Table 表的 Name 字段，那么 Redo 日志会记载 Name 字段在物理层的偏移量从而定位到 Name 字段的修改信息。但是我们写数据是一页一页的写的，一次必然要写 4KB，假如由于重启导致页数据损坏，正好损坏的不是 Name 字段的数据，而是这个页上其他的非修改数据。那么由于 Redo 日志是增量存储，上面值存储了修改操作的信息，而没有其他数据的信息，因此此时损坏页，Redo 日志就无法修复。而双写缓冲区则拥有全部数据就能修复。

**问题：双写缓冲区多一次写操作，对性能的影响大吗？**

答：不大，因为双写缓冲区的写操作是顺序写。经过测试，使用双写缓冲区与不使用相比，性能仅降低 5%-10%。

**问题：既然双写缓冲区写要是失败了，需要 Redo 日志进行恢复，那么假如写 Redo 日志失败了怎么办？**

答：不存在这种情况，因为每个事务在提交时都会将对应的 Redo 日志刷盘，只有 redo 日志刷盘成功了，事务才能算完成。

# AHI 自适应哈希 #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70 1]

自适应哈希索引是 Innodb 引擎自行研发的，用于提高 MySQL 的查询效率。

在 InnoDB 存储引擎内部自己去监控索引表，如果监控到某个索引经常用，那么就认为是热数据，然后内部自己创建一个 hash 索引，称之为自适应哈希索引（Adaptive Hash Index，AHI）。

创建以后，如果下次又查询到这个索引， 那么直接通过 hash 算法推导出记录的地址，直接一次就能查到数据，比重复去 B+tree 索引中查询三四次节点的效率高了不少。

MySQL 在哈希索引的设计上还采用了热点分散技术，这样的哈希索引在 MySQL 上默认是启动 8 个的，热点数据会分散到不同的哈希索引上，因此热数据访问时，能将请求分散到不同的哈希索引上，提高了并发访问的性能。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70 2]

# Buffer Pool #

## 什么是 Buffer Pool？ ##

InnoDB 为了缓存磁盘中的页，在 MySQL 服务器启动的时候就向操作系统申请了一片连续的内存，他们给这片内存起了个名，叫做 Buffer Pool。

默认情况下 Buffer Pool 只有 128M 大小（这个值其实是偏小的）。

启动服务器的时候可以通过配置 `innodb_buffer_pool_size` 参数的值来控制 Buffer Pool 大小，

## Buffer Pool 内部组成 ##

Buffer Pool 中默认的缓存页大小和在磁盘上默认的页大小是一样的，都是 16KB。

为了更好的管理这些在 Buffer Pool 中的缓存页，InnoDB 为每一个缓存页都创建了一些所谓的控制信息，这些控制信息包括该页所属的表空间编号、页号、 缓存页在 Buffer Pool 中的地址、链表节点信息、一些锁信息以及 LSN 信息，当然还有一些别的控制信息，我们称之为控制块。

PS：MySQL 大部分缓存的数据都在 Buffer Pool 中，缓存页就是数据，数据库查询出来的数据都会缓存到缓存页中，便于下次快速查询。控制块保存了缓存也的各种信息地址等，用来找缓存页  
![在这里插入图片描述][20210524103232602.png]

## Buffer Pool 中的链表结构 ##

### Free 链表 ###

Free 链表说简单些，就是将所有空闲的缓存页串起来，其实就是把空闲的缓存页对应的控制块的地址用一个链表来维护。这样下次有新数据进来，可以直接来 Free 链上直接找到空闲的缓存页。

Free 链还会有一个块用于存储，链表头，链表尾，以及链表上的数量。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70 3]

### Flush 链 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70 3]  
Flush 链的结构与 Free 链完全一样

既然我们知道 Buffer Pool 缓存的是数据库中查询出来的数据，那么必然会存在一个问题，假如数据被修改了怎么办？

因此 MySQL 把缓冲区上面这种被修改过的数据的控制块也用一个链表进行维护，以此来快速定位被修改过的数据，也被称为脏数据（未落盘的数据），因此 Flush 链又被称为脏链。

PS：MySQL 数据提交后，并不是立刻落盘的，而是依然在缓冲区里，最后会统一落盘。既然数据提交了自然会有 Redo 日志，假如数据库挂了，数据也是能恢复的。

**既然是脏数据为什么不知道把数据删掉？**

答：MySQL 本身数据并不是立刻落盘的。Flush 链上的数据，MySQL 会有定时任务去定时落盘。其次虽然是叫脏数据，但是本质上这些数据就是用户提交的数据，只是没落盘而已，读取时候直接读取是没有问题的。

### LRU 链表 ###

![在这里插入图片描述][20210524105619240.png]  
LRU 链表是一种最近最少使用淘汰链表，简单逻辑就是维护一个链表，假如这个数据使用了就提到链表头。假如链表满了，需要淘汰，就从链表尾淘汰。

而 MySQL 对 LRU 链表做了自己的优化改进

既然知道 MySQL 在缓冲区中缓存了查询的数据，但是查询的数据那么多，内存肯定放不下咋办？MySQL 就将数据用一个 LRU 链表进行维护，用来淘汰不常使用的数据，剩下的就是热门数据。

**MySQL 对 LRU 改进措施：**

1.  将 LRU 链表分为两部分，前面为热数据去（Young 区），后面为冷数据区（Old 区），Old 区大小占 37%。  
    优点：冷热链的切分，排除了全表扫描等类似的大数据量查询，直接把热门数据淘汰出缓冲区的情况。
2.  对冷链数据移动到热链上做了时间限定。限定时间内对冷链上数据的访问不会移动到热数据区，只有超过这个时间，再次访问冷链上的数据，才会被移动到热数据区。  
    优点：避免了短时间内全表扫描等大数据量频繁刷新导致，热门数据被移出热链的情况。
3.  热链的部分，并非每次访问都会向前移动。只有在热点的后 1/4 内的数据，在访问时才会移动到热链头部，减少移动带来的资源消耗，提升性能。

**参数：**  
**innodb\_old\_blocks\_pct：** 调整冷热区域占比占比，默认 37%。  
**innodb\_old\_blocks\_time：** 调整限定间隔时间，默认 1S

## MySQL 刷新数据落盘的途径 ##

MySQL 后台会有个定时器，定时将数据进行统一落盘，以不影响用 户线程处理正常的请求。

1.  **BUF\_FLUSH\_LIST：**从 flush 链表中刷新一部分页面到磁盘，刷新的速率取决 于当时系统是不是很繁忙。
2.  **BUF\_FLUSH\_LRU：**从 LRU 链表的冷数据中刷新一部分页面到磁盘。后台线程会定时从 LRU 链表尾部开始扫描一些页面，扫描的页面数量可以通 过系统变量 `innodb_lru_scan_depth` 来指定，如果从里边儿发现脏页，会把它们 刷新到磁盘。
3.  **BUF\_FLUSH\_SINGLE\_PAGE：** 有时候后台线程刷新脏页的进度比较慢，导致用户线程在准备加载一个磁盘页到 Buffer Pool 时没有可用的缓存页，这时就会尝试看看 LRU 链表尾部有没有可以直接释放掉的未修改页面，如果没有的话会不得不将 LRU 链表尾部的一个脏页同步刷新到磁盘（和磁盘交互是很慢的，这会降低处理用户请求的速度）。当然，有时候系统特别繁忙时，也可能出现用户线程批量的从 flush 链表中 刷新脏页的情况，很显然在处理用户请求过程中去刷新脏页是一种严重降低处理 速度的行为，这属于一种迫不得已的情况。

# InnoDB 的内存结构总结 #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70 4]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70]: /images/20221014/0cafd744cbc8437cbbd2f80a67d2b518.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70 1]: /images/20221014/274205edda834f6684e7922db6d78789.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70 2]: /images/20221014/2a102f90d95f4d1fa0e670bed4490de4.png
[20210524103232602.png]: /images/20221014/6c67b0246d9e4181935e448f2fbc2bf8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70 3]: /images/20221014/d0a962b23e4749f0b7bf4b05493f9605.png
[20210524105619240.png]: /images/20221014/98a83243604b4782aa45b4f2da06e028.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70 4]: /images/20221014/78f87cfd521a40ba98d9730e7757ba61.png