MySQL原理简介—5.存储模型和数据读写机制

本文涉及的产品
云数据库 RDS SQL Server,基础系列 2核4GB
云原生数据库 PolarDB 分布式版,标准版 2核8GB
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
简介: 本文介绍了MySQL中InnoDB存储引擎的物理存储结构和读写机制。主要内容包括:1. 为什么不能直接更新磁盘上的数据2. 数据页的概念3. 一行数据的存储4. 数据头的内容5. 行溢出和溢出页6. 数据页的物理结构7. 表空间的物理结构8. InnoDB存储模型及读写机制总结这些机制共同确保了InnoDB在高并发场景下的高效运行和数据一致性。

大纲

1.为什么不能直接更新磁盘上的数据

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

3.一行数据在磁盘上是如何存储的

4.一行数据中的NULL值是如何处理的

5.一行数据的数据头存储的是什么

6.一行数据的真实数据如何存储

7.数据在物理存储时的行溢出和溢出页

8.数据页的物理存储结构

9.表空间的物理存储结构

10.InnoDB存储模型及读写机制总结

 

前面介绍了MySQL的数据缓存机制和内存数据更新机制,接下来介绍MySQL的表空间、数据区、数据页等磁盘上的物理文件

 

1.为什么不能直接更新磁盘上的数据

为何MySQL要设计一套复杂的数据存取机制,即基于内存、日志、磁盘上的数据文件来完成数据读写?对于增改请求为何不直接更新磁盘文件?因为来一个请求就直接对磁盘文件进行随机读写,然后更新磁盘文件里的数据,这会导致执行请求的性能极差。

 

我们知道磁盘的随机读写性能是很差的,所以直接更新磁盘文件必然导致数据库完全无法抗下稍微高并发场景。于是MySQL才设计了一套数据缓存机制和内存数据更新机制。首先通过内存更新数据,然后写redo日志以及提交事务,最后通过后台线程不定时刷新内存里的数据到磁盘文件。通过这种方式可保证每个更新请求都更新内存,然后顺序写日志文件。

 

由于更新内存的性能是极高的,而且往磁盘文件顺序写日志的性能也比较高(顺序写的性能远高于随机写),所以这套机制可让MySQL在16核32G的机器上抗下每秒几千的读写请求。

 

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

当MySQL要更新数据时,并不是直接去更新磁盘文件的。而是首先把磁盘上的一些数据加载到内存里,然后对内存的数据进行更新,同时写redo日志。

 

但MySQL并非每次都把磁盘里的一条数据加载到内存里去进行更新。然后下次要更新别的数据时,再从磁盘里加载另外一条数据到内存里。因为这样每次一条一条的数据加载到内存进行更新,效率就太低了。

所以InnoDB存储引擎引入了数据页的概念。具体就是把数据组织成一页一页的结构,然后每一页有16KB。这样每次加载磁盘的数据到内存时,至少加载一页数据,甚至会通过预读机制加载多页数据。

假设要更新一条id=1的数据:

update xxx set xxx=xxx where id = 1;

那么此时MySQL会把id=1这条数据所在的一页数据都加载到内存里,这一页数据可能还包含了id=2等其他数据。然后当MySQL更新完id=1的数据后,如果接着需要更新id=2的数据时,就不用再次读取磁盘里的数据了。

 

这就是数据页的意义。磁盘和内存之间的数据交换通过数据页来执行,包括内存里更新后的脏数据被刷回磁盘时,也是以数据页为单位进行。

 

3.一行数据在磁盘上是如何存储的

(1)行格式

(2)变长字段在磁盘中是怎么存储的

(3)引入变长字段列表后,如何读取变长字段

(4)如果有多个变长字段,如何存放它们的长度

 

(1)行格式

我们创建表的时候可以指定表的行使用什么样的存储格式。比如下面的语句就指定使用compact格式进行存储。可以在建表的时候指定一个行存储的格式,也可以后续修改行存储的格式。

create table table_name (columns) row_format=compact
alter table table_nale row_format=compact

在compact行存储格式下,每一行实际存储时,格式如下。除了每个字段的值以外,还包含一些额外的信息。这些额外的信息就是用来描述这一行数据的。

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

(2)变长字段在磁盘中是怎么存储的

假设有两行数据,它的几个字段类型为varchar(10),char(1),char(1)。第一个字段是varchar(10),其长度是可变的。第一行数据可能类似"hello a a",第一个字段是hello,后两个字段是a。第二行数据可能类似"hi a a",第一个字段是hi,后两个字段也是a。

 

这时如果要把这两行数据写入磁盘文件,且要求这两行数据要挨在一起。那么磁盘文件里可能就有类似这样的数据:"hello a a hi a a"。其实我们平时看到表里的多行数据,落地到磁盘时,都是按上面的方式紧挨着存储的。

 

现在问题来了,假设要从磁盘文件读取上面形式的数据。也就是把"hello a a"这一行数据读取出来,那就比较困难了。因为没有标记也没有分隔符。所以MySQL引入了变长字段的长度列表,来解决标记和分隔符的问题。

 

也就是说,在存储"hello a a"这行数据时,要带上一些额外的附加信息。比如第一个就是这一行数据里的变长字段的长度列表。由于只有这个"hello"是varchar(10)类型的变长字段的值,而且它的长度是5,对应的十六进制是0x05,所以这个0x05就是这一行数据对应的变长字段的长度列表。

 

因此,需要在"hello a a"前面补充如下的额外信息:"0x05 null值列表 数据头 hello a a"。于是上面挨着的两行数据放在一起存储在磁盘文件里的格式就类似为:"0x05 null值列表 数据头 hello a a 0x02 null值列表 数据头 hi a a"。

 

(3)引入变长字段列表后,如何读取变长字段

现在假设要读取"hello a a"这行数据。

 

一.首先要确定表的字段类型

MySQL可知表里的三个字段的类型是varchar(10) char(1) char(1)。

 

二.然后读取第一个字段的值

由于第一个字段是变长的,所以从磁盘读出数据时,会从开头的变长字段的长度列表读到一个0x05的十六进制的数字。由此可知第一个变长字段的长度是5,于是便可以按照长度5去读取出第一个字段的值"hello"。

 

三.接着读取后面两个字段的值

由于后续两个字段都是char(1),长度都是固定的1个字符。于是就依次按照长度为1读取出后续两个字段的值,分别是"a"和"a"。这样就把该行数据"hello a a"读取出来了。

 

如果要读取第二行数据,也是先看一下第二行数据的变长字段列表。发现第一个变长字段的长度是0x02,于是读取长度为2的字段值,即"hi"。然后再读取两个长度固定为1的字符值,都是"a"。这样也把该行数据"hi a a"读出来了。

 

(4)如果有多个变长字段,如何存放它们的长度

比如一行数据有5个字段:varchar(10) varchar(5) varchar(20) char(1) char(1),其中3个是变长字段。假设这一行数据是这样的:"hello hi hao a a"。那么这一行数据会如何在磁盘中存储?

 

首先会在数据开头的变长字段长度列表中存储几个变长字段的长度。需要注意的是,变长字段的长度是逆序存储的。也就是先存放varchar(20)字段的长度,然后再存放varchar(5)字段的长度,最后才存放varchar(10)字段的长度。所以这一行数据实际存储在磁盘文件是长这样的:"0x03 0x02 0x03 null值列表 头字段 hello hi hao a a"。

 

4.一行数据中的NULL值如何处理

(1)为什么一行数据里的NULL值不能直接存储

(2)NULL值是以二进制bit位来存储的

(3)磁盘上的一行数据会怎么读出来

 

(1)为什么一行数据里的NULL值不能直接存储

磁盘上存储的每一行数据里除了有变长字段的长度列表外,还有另外一块特殊的数据区域,就是NULL值列表。

 

一行数据中有些字段值是NULL,NULL表示的是什么值都没有。如果在磁盘上存储时按"NULL"字符串存储,这样就太浪费空间了。

 

(2)NULL值是以二进制bit位来存储的

NULL值在磁盘上并不是通过字符串来存储的,而是通过bit位来存储的。具体来说,假设一行数据里有多个值是NULL。那么这多个NULL值,会以bit位的形式存放在NULL值列表中。

 

举个例子,有一张表如下:有5个字段,其中4个变长字段、1个定长字段,name字段不能为NULL。

create table customer (
    name varchar(10) not null,
    address varchar(20),
    gender char(1),
    job varchar(30),
    school varchar(50)
) row_format=compact;

在customer表里有一行数据:"jack NULL m NULL xx_school"。现在已经知道一行数据在磁盘上的compact存储格式为:

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

一.先看变长字段长度列表应该存放的内容

由于多个变长字段按照逆序存放,所以会先放school字段的长度,再放job字段、address字段、name字段的长度。

 

二.如果某变长字段的值是NULL

那么就不用在变长字段长度列表里存放这个变长字段的值长度。所以只有name和school两个变长字段有值。即需要把name和school的长度按照逆序放在变长字段长度列表中:

0x09 0x04 NULL值列表 数据头 column1=value1 column2=value2 ... columnN=valueN

三.对于所有允许值为NULL的字段,每个字段都有一个二进制bit位的值

如果bit值是1,则说明该字段是NULL;如果bit值是0,则说明该字段不是NULL。

 

四.上面的表4个字段都允许为NULL,所以每个字段都有一个bit位

对于数据"jack NULL m NULL xx_school"来说,4个bit位应该就是1010。

 

五.存放NULL值列表和存放变长字段的长度列表一样,也按逆序存放

所以4个bit位是0101,最后这一行数据是:

0x09 0x04 0101 数据头 column1=value1 column2=value2 ... columnN=valueN

六.实际存放NULL值列表时按照8个bit位的整数倍来存放

不会按4个bit位来存放,如果不足8个bit位则进行高位补0。所以最后的数据是:

0x09 0x04 00000101 数据头 column1=value1 column2=value2 ... columnN=valueN

(3)磁盘上的一行数据会怎么读出来

对于读取磁盘上存储的数据:

0x09 0x04 00000101 数据头 column1=value1 column2=value2 ... columnN=valueN

首先要把变长字段长度列表和NULL值列表读出来。通过分析可知有多少个变长字段,哪些字段是NULL。如果NULL值列表的某个bit位是1,则说明其对应的字段值是NULL。对于变长字段的值,就按变长字段长度列表来获得长度再根据长度去读取。对于固定长度字段的值,则直接按固定长度进行读取。

 

5.一行数据的数据头存储的是什么

在磁盘上存储数据时:

一.每一行数据都会有变长字段的长度列表

变长字段的长度列表,会通过逆序存放这一行数据里的变长字段的长度。

二.每一行数据都可能会有NULL值列表

允许为NULL的字段会有一个bit位标识该字段是否为NULL且逆序存放。

三.每一行数据还会有40个bit位的数据头

这个数据头是用来描述这行数据的

 

这40个bit位里面:

第一个和第二个bit位,都是预留位,没有含义;

第三个bit位是delete_mask:标识这行数据是否被删除。删除一行数据时不会马上把数据从磁盘上清理,而会在数据头进行标记;

第四个bit位是min_rec_mask:标记B+树里每一层的非叶子节点里的最小值;

接着有4个bit位的n_owned:这是一个记录数;

接着有13个bit位的heap_no:代表当前这行数据在记录堆里的记录;

接着有3个bit位的record_type:指的是这行数据的类型。0代表普通类型,1代表B+树非叶子节点,2代表最小值,3代表最大值;

最后有16个bit位的next_record:指向该行数据下一条数据的指针;

 

6.一行数据的真实数据如何存储

现已知一行数据在磁盘文件中存储时:首先会包含自己的变长字段的长度列表,然后是NULL值列表,接着是数据头,最后才是真实数据。

 

那么存储真实数据时,是怎么处理的呢?比如一行数据是"jack NULL m NULL xx_school"。那么它的真实存储大概如下:

0x09 0x04 00000101 00000000000000000000100000000000000011001 jack m xx_school

一开始是变长字段的长度,使用了十六进制来存储。然后是NULL值列表,指出了允许NULL的字段谁是NULL。接着是40个bit位的数据头,最后是真实数据值放在后面。

 

读取时先读取第一个字段。根据变长字段的长度列表知道长度是4,先读取出jack值。然后发现第二个字段是NULL,不用读取。接着第三个字段是定长字段,直接读取1个字符即可,也就是m值。接着第四个字段是NULL,也不用读取。第五个字段是变长字段。根据变长字段的长度列表知道长度是9,读取出xx_school。

 

但在磁盘上存储时,真实数据并不是以字符串的形式存储在磁盘上的。而是根据数据库指定的字符集编码,对字符串进行编码之后再存储。所以一行数据最终会如下所示进行存储:

0x09 0x04 00000101 00000000000000000000100000000000000011001 616161 636320 62626262

此外在实际存储一行数据时,还会在真实数据部分,加入一些隐藏字段。

一.首先有一个DB_ROW_ID字段

这是该行的唯一标识,是数据库针对该行设定的一个标识,不是主键ID。当没有给表指定主键和唯一索引时,该表会自动加一个ROW_ID作为主键。

二.接着有一个DB_TRX_ID字段

这是事务ID,代表着这是哪个事务更新的数据。

三.最后有个DB_ROLL_PTR字段

这是回滚指针,用来进行事务回滚。

 

所以加上隐藏字段后,一行数据可能看起来如下:

0x09 0x04 00000101 00000000000000000000100000000000000011001 00000000094C (DB_ROW_ID) 000000000032D (DB_TRX_ID) EA0000010078E (DB_ROL_PTR) 616161 636320 62626262

 

7.数据在物理存储时的行溢出和溢出页

每一行的数据都是放在一个数据页里的,这个数据页默认的大小是16KB。但如果一行数据的大小超过了数据页的大小时怎么办?

 

比如有一个表的字段类型是varchar(65532),意思就是最大可以包含65532个字符(65532字节),远大于16KB。

 

这时MySQL是这样处理的:首先会在一个数据页里尽量存储这一行所有字段数据,然后在特别长的字段中会仅仅包含一部分数据,同时包含一个20字节的指针指向其他数据页,那些数据页会用链表串联起来,存放这个特别长的字段的数据。

行溢出指的是:一行数据存储的内容太多,一个数据页放不下时,只能溢出这个数据页。把数据存放到其他数据页里,那些其他数据页就叫做溢出页。除了varchar(65532)这种字段,其他如text、blob字段,都可能出现溢出,然后一行数据会存储在多个数据页里。

 

总结:当往数据库插入一行数据时,实际上是在内存里插入一个有复杂存储结构的一行数据。然后随着一些条件的发生,这行数据会被刷到磁盘文件里去。在磁盘文件里存储时,这行数据会按照这个复杂的存储结构去存放。每一行的数据都放在数据页里。如果一行数据太大,则会产生行溢出,导致一行数据溢出到多个数据页里。那么这行数据在Buffer Pool可能就是存在于多个缓存页里的,刷入磁盘时也会用磁盘的多个数据页来存放这行数据。

 

8.数据页的物理存储结构

在MySQL中进行数据操作的最小单位是数据页,默认大小是16KB。当一行的数据量比16KB大时,会发生行溢出使用其他数据页存放。存放该行数据的数据页会使用一个20字节大小的指针指向其他溢出页。

 

存放一行的数据页会被拆分成多个部分:包括文件头、数据页头、最小记录和最大记录、多个数据行、空闲空间、数据页目录、文件尾部。下图所示包含了一个数据页的各个部分:

文件头会占38个字节;

数据页头会占56个字节;

最大记录和最小记录会占26个字节;

数据行区域大小是不固定的;

空闲区域的大小也是不固定的;

数据页目录的大小也是不固定的;

文件尾部会占8个字节;

 

一开始数据库初始化完后,数据页是空的,没有一行数据,对应于"多个数据行"的区域是空的。接着如果要插入一行数据,由于数据页和缓存页是对应的,所以会往一个空闲缓存页的多个数据行进行数据写入,并更新空闲区域。

 

9.表空间的物理存储结构

(1)什么是表空间

简单来说,我们平时创建的那些表,其实都对应一个表空间的。表空间在磁盘上都会对应着"表名.ibd"这样的一个磁盘数据文件。

 

在物理层面,表空间就是对应一些磁盘上的数据文件。系统的表空间可能会对应多个磁盘文件。我们创建的表对应的表空间,通常对应一个"表名.ibd"的数据文件。

 

在表空间的磁盘文件里,会有很多很多的数据页。一个数据页只有16KB,为了便于管理这么多数据页,表空间引入了数据区(extent)。一个数据区对应着连续的64个数据页。每个数据页16KB,所以一个数据区是1MB。一组数据区也就是256个数据区会被划分为一个组,所以一组数据区有256MB。

 

表空间的第一组数据区的第一个数据区的前3个数据页,都是固定的,里面存放了一些描述性的数据。比如FSP_HDR数据页,存放了表空间和这一组数据区的一些属性;比如IBUF_BITMAP数据页,存放了这一组数据页的所有insert buffer信息;比如INODE数据页,里面存放了一些特殊信息。

 

然后表空间的其他各组数据区的第一个数据区的头两个数据页,也都是固定的,里面存放了一些特殊信息:比如XDES数据页就是用来存放这一组数据区的一些相关属性的。

 

(2)表空间总结

平时创建的表都是有对应的表空间,每个表空间对应磁盘上的数据文件。表空间里有很多数据区组,256个数据区分成一组。每个数据区包又有64个数据页,所以每个数据区的大小是1MB。

 

表空间的第一组数据区的第一个数据区的头三个数据页,存放特殊信息。表空间的其他组数据区的第一个数据区的头两个数据页,也存放特殊信息。

 

当InnoDB执行增删改查操作时,会从磁盘上的表空间的数据文件里,加载数据页到Buffer Pool的缓存页里。

 

下图展示了一个表空间内部的存储结构:一个表空间内部会包含一组一组的数据区,每一组数据区包含256个数据区,每个数据区又包含64个数据页。

 

10.InnoDB存储模型及读写机制总结

在逻辑层面上,InnoDB的数据是插入一个一个的表中。在物理层面上,InnoDB的数据是插入一个一个的表空间。

 

表空间对应着磁盘文件,磁盘文件里存放的就是数据。在磁盘文件存放数据时,会被拆分为一个一个的数据区组。每个数据区组包含256个数据区,每个数据区包含64个数据页。每个数据页包含一行一行的数据。

 

数据页又包含了:文件头、数据页头、最小记录和最大记录、多个数据行、空闲空间、数据页目录、文件尾部。

 

每个数据行又附加了真实数据外的很多信息:变长字段的长度列表、null值列表、数据头、真实数据和隐藏字段。

 

通过数据页、数据区、数据行附加的特殊信息,可以让InnoDB在磁盘文件里实现B+索引、事务等复杂的机制。

 

当数据库执行增删改查时:必须把磁盘文件里的一个数据页加载到内存Buffer Pool中的缓存页里,然后增删改查都针对缓存页里的数据进行。

 

所以要读写数据时:会根据表找到一个表空间,通过表空间就可以找到对应的磁盘文件。通过磁盘文件就可以从里面找一个数据区组中的一个数据区。然后从该数据区中找一个数据页出来。最后就可以把这个数据页从磁盘加载到Buffer Pool缓存页里。

 

相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
16天前
|
自然语言处理 搜索推荐 关系型数据库
MySQL实现文档全文搜索,分词匹配多段落重排展示,知识库搜索原理分享
本文介绍了在文档管理系统中实现高效全文搜索的方案。为解决原有ES搜索引擎私有化部署复杂、运维成本高的问题,我们转而使用MySQL实现搜索功能。通过对用户输入预处理、数据库模糊匹配、结果分段与关键字标红等步骤,实现了精准且高效的搜索效果。目前方案适用于中小企业,未来将根据需求优化并可能重新引入专业搜索引擎以提升性能。
|
1月前
|
关系型数据库 MySQL 数据库
RDS用多了,你还知道MySQL主从复制底层原理和实现方案吗?
随着数据量增长和业务扩展,单个数据库难以满足需求,需调整为集群模式以实现负载均衡和读写分离。MySQL主从复制是常见的高可用架构,通过binlog日志同步数据,确保主从数据一致性。本文详细介绍MySQL主从复制原理及配置步骤,包括一主二从集群的搭建过程,帮助读者实现稳定可靠的数据库高可用架构。
88 9
RDS用多了,你还知道MySQL主从复制底层原理和实现方案吗?
|
1月前
|
存储 关系型数据库 MySQL
MySQL底层概述—6.索引原理
本文详细回顾了:索引原理、二叉查找树、平衡二叉树(AVL树)、红黑树、B-Tree、B+Tree、Hash索引、聚簇索引与非聚簇索引。
MySQL底层概述—6.索引原理
|
1月前
|
存储 缓存 关系型数据库
MySQL底层概述—3.InnoDB线程模型
InnoDB存储引擎采用多线程模型,包含多个后台线程以处理不同任务。主要线程包括:IO Thread负责读写数据页和日志;Purge Thread回收已提交事务的undo日志;Page Cleaner Thread刷新脏页并清理redo日志;Master Thread调度其他线程,定时刷新脏页、回收undo日志、写入redo日志和合并写缓冲。各线程协同工作,确保数据一致性和高效性能。
MySQL底层概述—3.InnoDB线程模型
|
1月前
|
SQL 监控 关系型数据库
MySQL原理简介—12.MySQL主从同步
本文介绍了四种为MySQL搭建主从复制架构的方法:异步复制、半同步复制、GTID复制和并行复制。异步复制通过配置主库和从库实现简单的主从架构,但存在数据丢失风险;半同步复制确保日志复制到从库后再提交事务,提高了数据安全性;GTID复制简化了配置过程,增强了复制的可靠性和管理性;并行复制通过多线程技术降低主从同步延迟,保证数据一致性。此外,还讨论了如何使用工具监控主从延迟及应对策略,如强制读主库以确保即时读取最新数据。
MySQL原理简介—12.MySQL主从同步
|
25天前
|
SQL 关系型数据库 MySQL
数据库数据恢复——MySQL简介和数据恢复案例
MySQL数据库数据恢复环境&故障: 本地服务器,安装的windows server操作系统。 操作系统上部署MySQL单实例,引擎类型为innodb,表空间类型为独立表空间。该MySQL数据库没有备份,未开启binlog。 人为误操作,在用Delete命令删除数据时未添加where子句进行筛选导致全表数据被删除,删除后未对该表进行任何操作。
|
26天前
|
存储 关系型数据库 MySQL
MySQL进阶突击系列(09)数据磁盘存储模型 | 一行数据怎么存?
文中详细介绍了MySQL数据库中一行数据在磁盘上的存储机制,包括表空间、段、区、页和行的具体结构,以及如何设计和优化行数据存储以提高性能。
|
2月前
|
关系型数据库 MySQL 数据库连接
数据库连接工具连接mysql提示:“Host ‘172.23.0.1‘ is not allowed to connect to this MySQL server“
docker-compose部署mysql8服务后,连接时提示不允许连接问题解决
|
1天前
|
消息中间件 缓存 NoSQL
缓存与数据库的一致性方案,Redis与Mysql一致性方案,大厂P8的终极方案(图解+秒懂+史上最全)
缓存与数据库的一致性方案,Redis与Mysql一致性方案,大厂P8的终极方案(图解+秒懂+史上最全)
|
1月前
|
关系型数据库 MySQL 数据库
Docker Compose V2 安装常用数据库MySQL+Mongo
以上内容涵盖了使用 Docker Compose 安装和管理 MySQL 和 MongoDB 的详细步骤,希望对您有所帮助。
178 42

相关产品

  • 云数据库 RDS MySQL 版