MySQL底层概述—1.InnoDB内存结构

大纲

1.InnoDB引擎架构

2.Buffer Pool

3.Page管理机制之Page页分类

4.Page管理机制之Page页管理

5.Change Buffer

6.Log Buffer

 

1.InnoDB引擎架构

(1)InnoDB引擎架构图

(2)InnoDB内存结构

 

(1)InnoDB引擎架构图

下面是InnoDB引擎架构图，主要分为内存结构和磁盘结构两大部分。

(2)InnoDB内存结构

 

2.Buffer Pool

(1)Buffer Pool基本概念

(2)如何判断数据页是否缓存在Buffer Pool

 

(1)Buffer Pool基本概念

Buffer Pool是缓冲池的意思。Buffer Pool的作用是缓存表数据与索引数据，减少磁盘IO，提升效率。

 

Buffer Pool由缓存数据页(Page)和对缓存数据页进行描述的控制块组成。控制块存储着缓存页的表空间、数据页号、在Buffer Pool中的地址等。

 

Buffer Pool默认大小是128M，以Page页为单位，Page页默认大小16K。而控制块的大小约为数据页的5%，大概是800字节。

注意：Buffer Pool大小为128M指的就是缓存页的总大小。控制块则一般占5%，所以每次会多申请6M的内存空间用于存放控制块。

 

(2)如何判断数据页是否缓存在Buffer Pool

MySQl中有一个哈希表数据结构：key是表空间号 + 数据页号，然后value就是缓存页对应的控制块。

当需要访问某个页的数据时：会先从哈希表中根据表空间号 + 页号看看是否存在对应的缓存页。如果有，则直接使用。如果没有，则从Free链表中选出一个空闲的缓存页，然后把磁盘中对应的页加载到该缓存页的位置。

 

3.Page管理机制之Page页分类

Buffer Pool的底层采用链表数据结构管理Page。在InnoDB访问表记录和索引时会在Buffer Pool中的Page页缓存，以后使用同样的表记录和索引时，就可以减少磁盘IO操作，提升效率。

 

Page根据状态可以分为三种类型：

一.Free Page：空闲Page，未被使用。

二.Clean Page：被使用Page，没被修改。

三.Dirty Page：被使用Page，已被修改。

脏页中的数据和磁盘的数据产生了不一致。

 

4.Page管理机制之Page页管理

(1)Free List空闲缓冲区

(2)Flush List需刷盘的缓冲区

(3)LRU List正在使用的缓冲区

 

针对上面的三种Page类型，InnoDB会通过三种链表结构来维护和管理。

 

(1)Free List表示空闲缓冲区(管理Free Page)

一.Free链表的初始化

Buffer Pool初始化时会先向操作系统申请连续的内存空间，然后把它划分成若干个控制块&缓存页，接着把所有空闲的缓存页对应的控制块作为节点放到一个链表中，这个链表就是Free链表。

 

二.Free链表的基节点

Free链表中只有一个基节点是不记录缓存页信息的(单独申请空间)，基节点存放了Free链表的头节点地址、尾节点地址和节点个数。

三.从磁盘加载数据页的流程

步骤1：首先从Free链表中取出一个空闲的控制块(对应缓存页)。

 

步骤2：然后把该缓存页对应的控制块信息填上，如缓存页所在的表空间、数据页号之类的信息。

 

步骤3：接着把该缓存页对应的Free链表节点(即控制块)从链表中移除，表示该缓存页已经被使用了。

 

(2)Flush List表示需要刷新到磁盘的缓冲区(管理Dirty Page)

Flush List管理的Dirty Page会按修改时间排序。InnoDB引擎为了提高处理效率，在每次修改缓存页后，并非立刻把修改刷新到磁盘上，而是在未来某个时间点进行刷新操作。

 

凡是被修改过的缓存页对应的控制块都会作为节点加入到Flush链表，Flush链表的结构与Free链表的结构相似。

脏页既存在于Flush链表中，也存在于LRU链表中，但它们互不影响。LRU链表负责管理Page的可用性和释放，Flush链表负责管理脏页的刷盘操作。

 

(3)LRU List表示正在使用的缓冲区(管理Clean Page和Dirty Page)

一.普通LRU算法

二.普通LRU链表的优缺点

三.改进型LRU算法

四.冷数据区的数据页何时会被转到到热数据区

 

缓冲区以midpoint为基点：链表的前面部分称为热数据列表，存放经常访问的数据，占63%。链表的后面部分称为冷数据列表，存放使用较少数据，占37%。

 

一.普通LRU算法

LRU = Least Recently Used(最近最少使用)，就是末尾淘汰法。新数据从链表头部加入，释放空间时从末尾淘汰。

步骤1：当要访问某个不在Buffer Pool中的数据页时，就把该数据页加载到Buffer Pool，并且把其缓存页对应的控制块作为节点添加到LRU链表的头部。

 

步骤2：当要访问某个在Buffer Pool中的数据页时，就把其缓存页对应的控制块移动到LRU链表头部。

 

步骤3：当需要释放空间时，从最末尾淘汰。

 

二.普通LRU链表的优缺点

优点：(热数据最快被获取)

所有最近使用的数据都在链表表头，最近未使用的数据都在链表表尾，可以保证热数据能最快被获取到。

 

缺点：(全表扫描 + 预读机制)

如果发生全表扫描，则可能将真正的热数据淘汰。由于MySQL中存在预读机制，很多预读的页会被放到LRU链表的表头。如果这些预读的页没用到，那么就可能会导致真正的热数据在尾部被淘汰。全表扫描的发生场景是：没有建立合适的索引或查询时使用select *等。

三.改进型LRU算法

改进的LRU链表分为热数据和冷数据两个部分。往LRU链表加入元素时并不从表头插入，而是从中间midpoint位置插入，也就是从磁盘中新读出的数据会放在冷数据区的头部。

 

如果数据很快被访问，那么Page就会向热数据列表头部移动；如果数据没有被访问，那么Page会逐步向冷数据列表尾部移动，等待淘汰。

四.冷数据区的数据页何时会被转到到热数据区

在对某个处于冷数据列表的缓存页进行第一次访问时，就会在它对应的控制块中记录下这个访问时间。

 

如果后续的访问时间与第一次访问的时间在某个时间间隔内，那么该缓存页就不会从冷数据列表移动到热数据列表的头部，否则就将该缓存页从冷数据列表移动到热数据列表的头部，从而避免全表扫描带来的访问频率很低但占用大量缓存页的问题。

 

这个间隔时间由innodb_old_blocks_time控制，默认是1s。这也就意味着，对于从磁盘加载到LRU链表冷数据列表的缓存页来说，如果第一次和最后一次访问的时间间隔小于1s，则不会加入热数据列表。

 

5.Change Buffer

(1)Change Buffer基本概念

(2)Change Buffer的数据更新流程

(3)为什么写缓冲区仅适用于二级索引页

(4)什么情况下会进行merge

(5)Change Buffer的使用场景(写多读少)

 

(1)Change Buffer基本概念

Change Buffer是写缓冲区，用于优化对二级索引(辅助索引)页的更新。

 

对于DML操作：如果请求的是辅助索引(非唯一键索引)且没有在缓冲池中，那么不会立刻将数据页加载到Buffer Pool中，而是会先在Change Buffer中记录数据的变更，等未来数据被读取时再将数据合并恢复放到Buffer Pool，以减少磁盘IO。

 

Change Buffer默认占Buffer Pool空间25%，最大占50%。可根据读写业务量进行调整，参数是innodb_change_buffer_max_size。

(2)Change Buffer的数据更新流程

情况1：

对于唯一索引，需要将数据页读入内存。然后判断没有冲突才插入更新值，语句执行结束。

 

情况2：

对于普通索引，更新一条记录时，步骤如下：

步骤一：如果该记录在Buffer Pool中存在，那么就直接在Buffer Pool中修改，进行一次内存操作。

步骤二：如果该记录在Buffer Pool中不存在(没有命中)，那么在不影响数据一致性的前提下，InnoDB会将该记录的更新操作缓存在Change Buffer中，先不用去磁盘查询数据，从而避免一次磁盘IO。

步骤三：当下次查询该记录时，InnoDB才会将数据页读入内存，然后执行Change Buffer中与该记录有关的操作。

 

(3)为什么写缓冲区仅适用于二级索引页

如果新增或修改发生在唯一索引中，那么InnoDB必须要做唯一性校验。此时就必须查询磁盘，进行一次IO操作。也就是会直接将记录查询到Buffer Pool中，然后在缓冲池修改，不需要在Change Buffer操作了。

 

如果新增或修改发生在非索引中，那么InnoDB还是要做唯一性校验。此时也必须查询磁盘，进行一次IO操作。

 

(4)什么情况下会进行merge

将Change Buffer中数据的变更应用到原数据页的过程称为merge。Change Buffer上的缓存数据是可以持久化的，以下情况会进行持久化：

一.访问这个数据页会触发merge

二.系统有后台线程会定期merge

三.在数据库正常关闭的过程中也会执行merge

 

(5)Change Buffer的使用场景

Change Buffer的主要目的是将记录的变更操作缓存下来，所以在merge发生前应当尽可能多的缓存变更信息，这样Change Buffer的优势发挥得就越明显。

 

应用场景是写多读少的业务。此时页面在写完后马上被访问的概率较小，Change Buffer使用效果最好。这种业务模型常见的就是账单类、日志类的系统。

 

6.Log Buffer

(1)Log Buffer的作用

(2)Log Buffer的刷盘策略

(3)Adaptive Hash Index

 

(1)Log Buffer的作用

Log Buffer指的是日志缓冲区。

 

Log Buffer是用来保存要写入磁盘log文件(Redo/Undo)的log数据。Log Buffer可以优化每次更新操作后要写文件而产生的磁盘IO问题，因为每次更新操作都是需要写log到redo log和undo log磁盘文件的。

 

Log Buffer日志缓冲区的内容会定期刷新到磁盘log文件中，Log Buffer日志缓冲区满时会自动将其刷新到磁盘。当遇到BLOB或多行更新的大事务时，增加日志缓冲区可节省磁盘IO。

 

Log Buffer主要是用于记录InnoDB引擎日志，InnoDB在DML操作时会产生redo和undo日志。

Log Buffer空间满了，会自动写入磁盘，默认16M。可以通过将innodb_log_buffer_size参数调大，减少磁盘IO频率。

 

(2)Log Buffer的刷盘策略

innodb_flush_log_at_trx_commit参数控制日志刷新行为，默认为1。

 

一.innodb_flush_log_at_trx_commit = 0

每隔1秒写日志文件Log Buffer和刷盘操作，最多丢失1秒数据。写日志文件Log Buffer -> OS cache -> 刷盘OS Cache -> 磁盘文件。

 

二.innodb_flush_log_at_trx_commit = 1

事务提交，立刻写日志文件和刷盘，数据不丢失，但是会频繁IO操作。

 

三.innodb_flush_log_at_trx_commit = 2

事务提交，立刻写日志文件Log Buffer，每隔1秒钟进行刷盘操作。

 

(3)Adaptive Hash Index

自适应哈希索引，用于优化对Buffer Pool数据的查询，InnoDB存储引擎会监控对表索引的查找。

 

自适应哈希索引指的是：如果观察到建立哈希索引可以带来速度的提升，则建立哈希索引。InnoDB存储引擎会自动根据访问的频率和模式来为某些页建立哈希索引。