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

本文涉及的产品
RDS SQL Server Serverless,2-4RCU 50GB 3个月
推荐场景:
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS SQL Server,基础系列 2核4GB
简介: 本文介绍了InnoDB引擎的关键组件和机制,包括引擎架构、Buffer Pool、Page管理机制、Change Buffer、Log Buffer及Adaptive Hash Index。

大纲

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存储引擎会自动根据访问的频率和模式来为某些页建立哈希索引。

 

相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
1月前
|
存储 缓存 关系型数据库
MySQL底层概述—9.ACID与事务
本文介绍了数据库事务的ACID特性(原子性、一致性、隔离性、持久性),以及事务控制的演进过程,包括排队、排它锁、读写锁和MVCC(多版本并发控制)。文章详细解释了每个特性的含义及其在MySQL中的实现方式,并探讨了事务隔离级别的类型及其实现机制。重点内容包括:ACID特性(原子性、持久性、隔离性和一致性的定义及其实现方式)、事务控制演进(从简单的全局排队到复杂的MVCC,逐步提升并发性能)、MVCC机制(通过undo log多版本链和Read View实现高效并发控制)、事务隔离级别(析了四种隔离级别(读未提交、读已提交、可重复读、可串行化)的特点及适用场景)、隔离级别与锁的关系。
|
1月前
|
存储 SQL 关系型数据库
MySQL底层概述—2.InnoDB磁盘结构
InnoDB磁盘结构主要包括表空间(Tablespaces)、数据字典(Data Dictionary)、双写缓冲区(Double Write Buffer)、重做日志(redo log)和撤销日志(undo log)。其中,表空间分为系统、独立、通用、Undo及临时表空间,分别用于存储不同类型的数据。数据字典从MySQL 8.0起不再依赖.frm文件,转而使用InnoDB引擎存储,支持事务原子性DDL操作。
244 100
MySQL底层概述—2.InnoDB磁盘结构
|
1月前
|
SQL 关系型数据库 MySQL
MySQL底层概述—10.InnoDB锁机制
本文介绍了:锁概述、锁分类、全局锁实战、表级锁(偏读)实战、行级锁升级表级锁实战、间隙锁实战、临键锁实战、幻读演示和解决、行级锁(偏写)优化建议、乐观锁实战、行锁原理分析、死锁与解决方案
117 24
MySQL底层概述—10.InnoDB锁机制
|
1月前
|
缓存 算法 关系型数据库
MySQL底层概述—8.JOIN排序索引优化
本文主要介绍了MySQL中几种关键的优化技术和概念,包括Join算法原理、IN和EXISTS函数的使用场景、索引排序与额外排序(Using filesort)的区别及优化方法、以及单表和多表查询的索引优化策略。
109 22
MySQL底层概述—8.JOIN排序索引优化
|
1月前
|
SQL 关系型数据库 MySQL
MySQL底层概述—7.优化原则及慢查询
本文主要介绍了:Explain概述、Explain详解、索引优化数据准备、索引优化原则详解、慢查询设置与测试、慢查询SQL优化思路
124 15
MySQL底层概述—7.优化原则及慢查询
|
1月前
|
存储 关系型数据库 MySQL
MySQL底层概述—6.索引原理
本文详细回顾了:索引原理、二叉查找树、平衡二叉树(AVL树)、红黑树、B-Tree、B+Tree、Hash索引、聚簇索引与非聚簇索引。
MySQL底层概述—6.索引原理
|
1月前
|
存储 缓存 关系型数据库
MySQL底层概述—5.InnoDB参数优化
本文介绍了MySQL数据库中与内存、日志和IO线程相关的参数优化,旨在提升数据库性能。主要内容包括: 1. 内存相关参数优化:缓冲池内存大小配置、配置多个Buffer Pool实例、Chunk大小配置、InnoDB缓存性能评估、Page管理相关参数、Change Buffer相关参数优化。 2. 日志相关参数优化:日志缓冲区配置、日志文件参数优化。 3. IO线程相关参数优化: 查询缓存参数、脏页刷盘参数、LRU链表参数、脏页刷盘相关参数。
MySQL底层概述—5.InnoDB参数优化
|
1月前
|
存储 SQL 关系型数据库
MySQL底层概述—4.InnoDB数据文件
本文介绍了InnoDB表空间文件结构及其组成部分,包括表空间、段、区、页和行。表空间是最高逻辑层,包含多个段;段由若干个区组成,每个区包含64个连续的页,页用于存储多条行记录。文章还详细解析了Page结构,分为通用部分(文件头与文件尾)、数据记录部分和页目录部分。此外,文中探讨了行记录格式,包括四种行格式(Redundant、Compact、Dynamic和Compressed),重点介绍了Compact行记录格式及其溢出机制。最后,文章解释了不同行格式的特点及应用场景,帮助理解InnoDB存储引擎的工作原理。
MySQL底层概述—4.InnoDB数据文件
|
1月前
|
存储 缓存 关系型数据库
MySQL底层概述—3.InnoDB线程模型
InnoDB存储引擎采用多线程模型,包含多个后台线程以处理不同任务。主要线程包括:IO Thread负责读写数据页和日志;Purge Thread回收已提交事务的undo日志;Page Cleaner Thread刷新脏页并清理redo日志;Master Thread调度其他线程,定时刷新脏页、回收undo日志、写入redo日志和合并写缓冲。各线程协同工作,确保数据一致性和高效性能。
MySQL底层概述—3.InnoDB线程模型
|
6天前
|
关系型数据库 MySQL 数据库连接
docker拉取MySQL后数据库连接失败解决方案
通过以上方法,可以解决Docker中拉取MySQL镜像后数据库连接失败的常见问题。关键步骤包括确保容器正确启动、配置正确的环境变量、合理设置网络和权限,以及检查主机防火墙设置等。通过逐步排查,可以快速定位并解决连接问题,确保MySQL服务的正常使用。
114 82

相关产品

  • 云数据库 RDS MySQL 版