MySQL（高级特性篇） 07 章——InnoDB数据存储结构

qw9492025-01-16 20:21

一、数据库的存储结构：页

索引结构给我们提供了高效的索引方式，不过索引信息以及数据记录都是保存在文件上的，确切地说是存储在页结构中。另一方面，索引是在存储引擎中实现的，MySQL服务器上的存储引擎负责对表中数据的读取和写入工作。不同存储引擎中存放的格式一般是不同的，甚至有的存储引擎，比如Memory，都不用磁盘来存储数据

由于InnoDB是MySQL的默认存储引擎，所以本章剖析InnoDB存储引擎的数据存储结构

（1）磁盘与内存交互基本单位：页

  1. InnoDB将数据划分为若干个页 ，InnoDB中页的大小默认为16KB
  2. 以页作为磁盘和内存之间交互的基本单位，也就是一次最少从磁盘中读取16KB的内容到内存中，一次最少把内存中16KB的内容刷新到磁盘中。也就是说，在数据库中，不论是读一行，还是读多行，都是将这些行所在的页进行加载。也就是说，数据库管理存储空间的基本单位是页（Page），数据库I/O操作的基本单位是页。一个页中可以存储多个行记录
  3. 记录是按照行来存储的，但是数据库的读取并不以行为单位，否则一次读取（也就是一次I/O操作）只能处理一行数据，效率会非常低
  4. 图示：

（2）页结构概述

  1. 页a、页b、页c...页n这些页可以不再物理结构上相连，只要通过双向链表相关联即可。每个数据页中的记录会按照主键值从小到大的顺序组成一个单向链表，每个数据页都会为存储在它里边的记录生成一个页目录，在通过主键查找某条记录的时候，可以在页目录中使用二分法快速定位到对应的槽，然后再遍历该槽对应分组中的记录即可快速找到指定的记录

（3）页的大小

  1. 不同的数据库管理系统（简称DBMS）的页大小不同。比如在MySQL的InnoDB存储引擎中，默认页的大小是16KB，我们可以通过下面的命令来进行查看：
  2. SQL Server中页的大小为8KB，而在Oracle中我们用术语"块"（Block）来代表"页"，Oracle支持的块大小为2KB，4KB，8KB，16KB，32KB和64KB

（4）页的上层结构

  1. 另外在数据库中，还存在着区（Extent）、段（Segment）和表空间（TableSpace）的概念。行、页、区、段、表空间的关系如下图所示：
  2. 区（Extent）是比页大一级的存储结构，在InnoDB存储引擎中，一个区会分配64个连续的页。因为InnoDB中的页默认大小是16KB，所以一个区的大小是64*16KB=1MB
  3. 段（Segment）由一个或多个区组成，区在文件系统中是一个连续分配的存储空间（在InnoDB中是连续的64个页），不过在段中，不要求区与区之间是相邻的。段是数据库中分配的单位，不同类型的数据库对象以不同的段形式存在。当我们创建数据表、索引的时候，就会相应创建对应的段，比如创建一张表时会创建一个表段，创建一个索引时会创建一个索引段
  4. 表空间（TableSpace）是一个逻辑容器，表空间存储的对象是段，在一个表空间中可以有一个或多个段，但是一个段只能属于一个表空间。数据库由一个或多个表空间组成，表空间从管理上可以划分为系统表空间、用户表空间、撤销表空间、临时表空间等

二、页的内部结构

页如果按类型划分的话，常见的有数据页（保存B+树节点）、系统页、Undo页和事务数据页等。数据页是我们最常使用的页

数据页的16KB大小的存储空间被划分为七个部分，分别是文件头部（File Header）、页面头部（Page Header）、最大最小记录（Infimum+supremum）、用户记录（User Records）、空闲空间（Free Space）、页目录（Page Directory）、文件尾部（File Trailer）

页结构的示意图如下所示：

这七个部分的作用分别如下，我们简单梳理如下表所示：

（1）第1部分：File Header（文件头部）和File Trailer（文件尾部）

2.1.1File Header（文件头部）（38字节）

  1. 作用：描述各种页的通用信息（比如页的编号、其上一页、下一页是谁）

  2. 大小：38字节

  3. 构成：

  4. FIL_PAGE_OFFSET：每一个页都有单独的页号，就跟你的身份证号码一样，InnoDB通过页号可以唯一确定一个页

  5. FIL_PAGE_TYPE：这个代表当前页的类型

    类型名称 十六进制 描述
    FIL_PAGE_TYPE_ALLOCATED 0x0000 最新分配，还没有使用
    FIL_PAGE_UNDO_LOG 0x0002 Undo日志页
    FIL_PAGE_INODE 0x0003 段信息节点
    FIL_PAGE_IBUF_FREE_LIST 0x0004 Insert Buffer空闲列表
    FIL_PAGE_IBUF_BITMAP 0x0005 Insert Buffer位图
    FIL_PAGE_TYPE_SYS 0x0006 系统页
    FIL_PAGE_TYPE_TRX_SYS 0x0007 事务系统数据
    FIL_PAGE_TYPE_FSP_HDR 0x0008 表空间头部信息
    FIL_PAGE_TYPE_XDES 0x0009 扩展描述页
    FIL_PAGE_TYPE_BLOB 0x000A 溢出页
    FIL_PAGE_INDEX 0x45BF 索引页，也就是我们所说的数据页

  6. FIL_PAGE_PREV和FIL_PAGE_NEXT：InnoDB都是以页为单位存放数据的，如果数据分散到多个不连续的页中存储的话需要把这些页关联起来，FIL_PAGE_PREV和FIL_PAGE_NEXT就分别代表本页的上一个和下一个页的页号。这样通过建立一个双向链表就把许许多多的页就都串联起来了，保证这些页之间不需要物理上的连续，而是逻辑上的连续

  7. FIL_PAGE_SPACE_OR_CHKSUM：代表当前页面的校验和

    1. 什么是校验和：就是对于一个很长的字节串来说，我们会通过某种算法来计算一个比较短的值，来代表这个很长的字节串，这个比较短的值就称为校验和。在比较两个很长的字节串之前，先比较这两个长字节串的校验和，如果校验和都不一样，则两个长字节串肯定是不同的，所以省去了直接比较两个长字节串的时间损耗
    2. 文件头部和文件尾部都有属性：FIL_PAGE_SPACE_OR_CHKSUM
    3. 作用：InnoDB存储引擎以页为单位把数据加载到内存中处理，如果该页中的数据在内存中被修改了，那么在修改后的某个时间需要把数据同步到磁盘中。但是在同步了一半的时候断电了，造成了该页传输的不完整。为了检测一个页是否完整（也就是在同步的时候有没有发生只同步一般的尴尬情况），这时可以通过文件尾的校验和（checksum值）与文件头的校验和做对比，如果两个值不相等，则证明页的传输有问题，需要重新进行传输，否则认为页的传输已经完成
    4. 具体的：每当一个页面在内存中修改了，在同步之前就要把它的校验和算出来，因为File Header在页的前边，所以校验和会被首先同步到磁盘，当完全写完时，校验和也会被写到页的尾部，如果完全同步成功，则页的首部和尾部的校验和应该是一致的。如果同步到一半断电了，那么在File Header中的校验和就代表着已经修改过的页，而File Trailer中的校验和代表着原先的页，二者不同则意味着同步中间出了错。这里，校验方式就是采用Hash算法进行校验

  8. FIL_PAGE_LSN：页面被最后修改对应的日志序列位置（英文名是：Log Sequence Number）

2.1.2File Trailer（文件尾部）（8字节）

  1. 前4个字节代表页的校验和：这个部分是和File Header中的校验和相对应的
  2. 后4个字节代表页面最后修改时对应的日志序列位置（LSN）：这个部分也是为了校验页的完整性的，如果首部和尾部的LSN值校验不成功的话，就说明同步过程出现了问题

（2）第2部分：空闲空间、用户记录和最大最小记录

页的主要作用是存储记录，所以"最大和最小记录"和"用户记录"部分占了页结构的主要空间

2.2.1Free Space（空闲空间）

  1. 我们自己存储的记录会按照指定的行格式存储到User Records部分。但是在一开始生成页的时候，其实并没有User Records这个部分，每当我们插入一条记录，都会从Free Space部分，也就是尚未使用的存储空间中申请一个记录大小的空间划分到User Records部分，当Free Space部分的空间全部被User Records部分替代掉之后，也就意味着这个页使用完了，如果还有新的记录插入的话，就需要去申请新的页了
  2. 图示：

2.2.2User Records（用户记录）

  1. User Records中的这些记录按照指定的行格式一条一条地摆在User Records部分，互相之间形成单链表
  2. 用户记录里的一条条数据如何记录？这里就需要讲讲行格式里的记录头信息

2.2.3Infimum+Supremum（最大最小记录）

  1. 记录可以比较大小吗？是的，记录可以比大小，对于一条完整的记录来说，比较记录的大小就是比较主键的大小。比方说，我们插入的4行记录的主键值分别是：1，2，3，4，这也就意味着这4条记录是从小到大依次递增
  2. InnoDB规定的最小记录和最大记录这两条记录的构造十分简单，都是由5字节大小的记录头信息和8字节大小的一个固定部分组成的，如图所示：
  3. 这两条记录不是我们自己定义的记录，所以它们并不存放在User Records部分，它们被单独放在一个称为Infimum+Supremum的部分，如图所示：

（3）第3部分：页目录和页面头部

2.3.1Page Directory（页目录）

  1. 为什么需要页目录？在页中，记录是以单向链表的形式进行存储的。单向链表的特点就是插入、删除非常方便，但是检索效率不高，最差的情况下需要遍历链表上的所有节点才能完成检索。因此在页结构中专门设计了页目录这个模块，专门给记录做个目录，通过二分查找法的方式进行检索，提升效率

  2. 需求：根据主键值查找页中的某条记录，如何实现快速查找呢？

    sql 复制代码 
    SELECT * FROM page_demo WHERE c1 = 3;
    1. 方式一：从Infimum记录（最小记录）开始，沿着链表一直往后找，总有一天会找到（或者找不到），在找的时候还能投机取巧，因为链表中各个记录的值是按照从小到大顺序排列的，所以当链表的某个节点代表的记录的主键值大于你想要查找的主键值时，你就可以停止查找了，因为该节点后边的节点的主键值依次递增
    2. 方式二：使用页目录，二分查找法（1）将该页中所有的记录分成几个组，这些记录包括最小记录和最大记录，但不包括标记为"已删除"的记录（2）第1组，也就是最小记录所在的分组只有1个记录；最后一组，就是最大记录所在的分组，会有1-8条记录；其余的组记录数量在4-8条之间。这样做的好处是，除了第1组（最小记录所在组）以外，其余组的记录数会尽量平分（3）在每个组中最后一条记录的头信息中会存储该组一共有多少条记录，作为n_owned字段（4）页目录用来存储每组最后一条记录的地址偏移量，这些地址偏移量会按照先后顺序存储起来，每组的地址偏移量也被称之为槽（slot），每个槽相当于指针指向了不同组的最后一个记录

  3. 举例：现在的page_demo表中正常的记录共有6条，InnoDB会把它们分成两组，第一组中只有一个最小记录，第二组中是剩余的5条记录。如下图：

  4. 从这个图中我们需要注意这么几点：

    1. 现在页目录部分中有两个槽，也就意味着我们的记录被分成了两个组，槽1中的值是112，代表最大记录的地址偏移量（就是从页面的0字节开始数，数112个字节）；槽0中的值是99，代表最小记录的地址偏移量
    2. 注意最小和最大记录的头信息中的n_owned属性（1）最小记录的n_owned值为1，这就代表着以最小记录结尾的这个分组中只有1条记录，也就是最小记录本身（2）最大记录的n_owned值为5，这就代表着以最大记录结尾的这个分组中只有5条记录，包括最大记录本身还有我们自己插入的4条记录

  5. 用箭头指向的方式替代数字，这样更易于我们理解，修改后如下：

  6. 再换个角度看一下：（单纯从逻辑上看一下这些记录和页目录的关系）

  7. 为什么最小记录的n_owned值为1，而最大记录的n_owned值为5呢？

    1. InnoDB规定：对于最小记录所在的分组只能有1条记录，最大记录所在的分组拥有的记录条数只能在1~8条之间，剩下的分组中记录的条数范围只能在是4~8条之间

    2. 分组是按照下边的步骤进行的：（1）初始情况下一个数据页里只有最小记录和最大记录两条记录，它们分属于两个分组（2）之后每插入一条记录，都会从页目录中找到主键值比本记录的主键值大并且差值最小的槽，然后把该槽对应的记录的n_owned值加1，表示本组内又添加了一条记录，直到该组中的记录数等于8个（3）在一个组中的记录数等于8个后再插入一条记录时，会将组中的记录拆分成两个组，一个组中4条记录，另一个5条记录。这个过程会在页目录中新增一个槽来记录这个新增分组中最大的那条记录的偏移量

  8. 利用Page Directory查找的步骤：

    1. 这里只保留了16条记录的记录头信息中的n_owned和next_record属性，省略了各个记录之间的箭头

    2. 现在看怎么从这个页目录中查找记录。因为各个槽代表的记录的主键值都是从小到大排序的，所以我们可以使用二分法来进行快速查找

    3. 5个槽的编号分别是：0、1、2、3、4，所以初始情况下最低的槽就是low=0，最高的槽就是high=4

    4. 比方说，我们想找主键值为6的记录，过程是这样的：

    5. 计算中间槽的位置：(0+4)/2=2，所以查看槽2对应记录的主键值为8，又因为8 > 6，所以设置high=2，low保持不变

    6. 重新计算中间槽的位置：(0+2)/2=1，所以查看槽1对应的主键值为4，又因为4 < 6，所以设置low=1，high保持不变

    7. 因为high - low的值为1，所以确定主键值为6的记录在槽2对应的组中。此刻我们需要找到槽2中主键值最小的那条记录，然后沿着单向链表遍历槽2中的记录

    8. 但是我们前边又说过，每个槽对应的记录都是该组中主键值最大的记录，这里槽2对应的记录是主键值为8的记录，怎么定位一个组中最小的记录呢？别忘了各个槽都是挨着的，我们可以很轻易的拿到槽1对应的记录（主键值为4），该条记录的下一条记录就是槽2中主键值最小的记录，该记录的主键值为5。所以我们可以从这条主键值为5的记录出发，遍历槽2中的各条记录，直到找到主键值为6的那条记录即可。由于一个组中包含的记录条数只能是1~8条，所以遍历一个组中的记录的代价是很小的

  9. 小结：在一个数据页中查找指定主键值的记录的过程分为两步：

    1. 通过二分法确定该记录所在的槽，并找到该槽所在分组中主键值最小的那条记录
    2. 通过记录的next_record属性遍历该槽所在的组中的各个记录

2.3.2Page Header（页面头部）

  1. 为了能得到一个数据页中存储的记录的状态信息，比如本页中已经存储了多少条记录，第一条记录的地址是什么，页目录中存储了多少个槽等等，特意在页中定义了一个叫Page Header的部分，这个部分占用固定的56个字节，专门存储各种状态信息：

    名称 占用空间大小 描述
    PAGE_N_DIR_SLOTS 2字节 在页目录中的槽数量
    PAGE_HEAP_TOP 2字节 还未使用的空间最小地址，也就是说从该地址之后就是Free Space
    PAGE_N_HEAP 2字节 本页中的记录的数量（包括最小和最大记录以及标记为删除的记录）
    PAGE_FREE 2字节 第一个已经标记为删除的记录的记录地址（各个已删除的记录通过next_record也会组成一个单链表，这个单链表中的记录可以被重新利用）
    PAGE_GARBAGE 2字节 已删除记录占用的字节数
    PAGE_LAST_INSERT 2字节 最后插入记录的位置
    PAGE_DIRECTION 2字节 记录插入的方向
    PAGE_N_DIRECTION 2字节 一个方向连续插入的记录数量
    PAGE_N_RECS 2字节 该页中记录的数量（不包括最小和最大记录以及被标记为删除的记录）
    PAGE_MAX_TRX_ID 8字节 修改当前页的最大事务ID，该值仅在二级索引中定义
    PAGE_LEVEL 2字节 当前页在B+树中所处的层级
    PAGE_INDEX_ID 8字节 索引ID，表示当前页属于哪个索引
    PAGE_BTR_SEG_LEAF 10字节 B+树叶子段的头部信息，仅在B+树的Root页定义
    PAGE_BTR_SEG_TOP 10字节 B+树非叶子段的头部信息，仅在B+树的Root页定义

  2. PAGE_DIRECTION：假如新插入的一条记录的主键值比上一条记录的主键值大，我们说这条记录的插入方向是右边，反之则是左边。用来表示最后一条记录插入方向的状态就是PAGE_DIRECTION

  3. PAGE_N_DIRECTION：假设连续几次插入新记录的方向都是一致的，InnoDB会把沿着同一个方向插入记录的条数记下来，这个条数就用PAGE_N_DIRECTION这个状态表示。当然，如果最后一条记录的插入方向改变了的话，这个状态的值会被清零重新统计

（4）从数据页的角度看B+树如何查询

  1. 一棵B+树按照节点类型可以分成两部分：
    1. 叶子节点，B+树最底层的节点，节点的高度为0，存储行记录
    2. 非叶子节点，节点的高度大于0，存储索引键和页面指针，并不存储行记录本身
  2. 当我们从页结构来理解B+树的结构的时候，可以帮我们理解一些通过索引进行检索的原理：
    1. B+树是如何进行记录检索的？如果通过B+树的索引查询行记录，首先是从B+树的根开始，逐层检索，直到找到叶子节点，也就是找到对应的数据页为止，将数据页加载到内存中，页目录中的槽（slot)采用二分查找的方式先找到一个粗略的记录分组，然后再在分组中通过链表遍历的方式查找记录。
    2. 普通索引和唯一索引在查询效率上有什么不同？唯一索引就是在普通索引上增加了约束性，也就是关键字唯一，找到了关键字就停止检索。而普通索引，可能会存在用户记录中的关键字相同的情况，根据页结构的原理，当我们读取一条记录的时候，不是单独将这条记录从磁盘中读出去，而是将这个记录所在的页加载到内存中进行读取。InnoDB存储引擎的页大小为16KB，在一个页中可能存储着上千个记录，因此在普通索引的字段上进行查找也就是在内存中多几次 "判断下一条记录"的操作，对于CPU来说，这些操作所消耗的时间是可以忽略不计的。所以对一个索引字段进行检索，采用普通索引还是唯一索引在检索效率上基本上没有差别

三、InnoDB行格式（或记录格式）

我们平时的数据以行为单位来向表中插入数据，这些记录在磁盘上的存放方式也被称为行格式或者记录格式。InnoDB存储引擎设计了四种不同类型的行格式，分别是Compact、Redundant、Dynamic和Compressed行格式。查看MySQL8的默认行格式：

也可以使用如下语法查看具体表使用的行格式：

sql 复制代码 
SHOW TABLE STATUS like '表名'\G

（1）指定行格式的语法

  1. 创建表时：

    sql 复制代码 
    CREATE TABLE 表名 (列的信息) ROW_FORMAT=行格式名称;

  2. 修改表时：

    sql 复制代码 
    ALTER TABLE 表名 ROW_FORMAT=行格式名称;

（2）COMPACT行格式

在MySQL 5.1版本中，默认设置为Compact行格式。一条完整的记录其实可以被分为记录的额外信息和记录的真实数据两大部分

3.2.1变长字段长度列表

  1. MySQL支持一些变长的数据类型，比如VARCHAR(M)、VARBINARY(M)、TEXT类型、BLOB类型，这些数据类型修饰的列称为变长字段，变长字段中存储多少字节的数据不是固定的，所以我们在存储真实数据的时候需要顺便把这些数据占用的字节数也存起来。在Compact行格式中，把所有变长字段的真实数据占用的字节长度都存放在记录的开头部位，从而变成一个变长字段长度列表
  2. 注意：这里面存储的变长长度和字段顺序是反过来的。比如两个varchar字段在表结构的顺序是a(10)，b(15)。那么在变长字段长度列表中存储的长度顺序就是15，10，是反过来的

3.2.2NULL值列表

  1. Compact行格式会把可以为NULL的列统一管理起来，存在一个标记为NULL值列表中。如果表中没有允许存储NULL的列，则NULL值列表也不存在了
  2. 为什么定义NULL值列表？之所以要存储NULL是因为数据都是需要对齐的，如果没有标注出来NULL值的位置，就有可能在查询数据的时候出现混乱。如果使用一个特定的符号放到相应的数据位表示空置的话，虽然能达到效果，但是这样很浪费空间，所以直接就在行数据得头部开辟出一块空间专门用来记录该行数据哪些是非空数据，哪些是空数据，格式如下：
    1. 二进制位的值为1时，代表该列的值为NULL
    2. 二进制位的值为0时，代表该列的值不为NULL
  3. 注意：同样顺序也是反过来存放的
  4. 例如：字段a、b、c，其中a是主键，在某一行中存储的数依次是a=1、b=null、c=2。那么Compact行格式中得NULL值列表中存的10。第一个1表示b是null，第二个0表示c不为null。这里之所以没有a是因为数据库会自动跳过主键，因为主键肯定是非NULL且唯一的，在NULL值列表的数据中就会自动跳过主键

3.2.3记录头信息（5字节）

  1. 记录的行格式示意图：

  2. 这些记录头信息中各个属性如下：

    名称 大小（单位：bit） 描述
    预留位1 1 没有使用
    预留位2 1 没有使用
    delete_mask 1 标记该记录是否被删除
    mini_rec_mask 1 B+树的每层非叶子节点中的最小记录都会添加该标记
    n_owned 4 表示当前记录拥有的记录数
    heap_no 13 表示当前记录在记录堆的位置信息
    record_type 3 表示当前记录的类型，0表示普通记录，1表示B+树非叶子节点记录，2表示最小记录，3表示最大记录
    next_record 16 表示下一条记录的相对位置

  3. delete_mask：这个属性标记着当前记录是否被删除，占用1个二进制位

    1. 值为0：代表记录并没有被删除
    2. 值为1：代表记录被删除掉了

  4. 被删除的记录为什么还在页中存储呢？你以为它删除了，可它还在真实的磁盘上。这些被删除的记录之所以不立即从磁盘上移除，是因为移除它们之后其他的记录在磁盘上需要重新排列，导致性能消耗。所以只是打一个删除标记而已，所有被删除掉的记录都会组成一个所谓的垃圾链表，在这个链表中的记录占用的空间称之为可重用空间，之后如果有新记录插入到表中的话，可能把这些被删除的记录占用的存储空间覆盖掉

  5. min_record_mask：B+树的每层非叶子节点中的最小记录都会添加该标记

    1. 值为0：意味着不是B+树非叶子节点中的最小记录
    2. 值为1：意味着是B+树中非叶子节点中的最小记录

  6. record_type：这个属性表示当前记录的类型，一共有四种类型的记录

    1. 0：表示普通记录
    2. 1：表示B+树中非叶子节点里的记录
    3. 2：表示最小记录
    4. 3：表示最大记录

  7. heap_no：表示当前记录在本页中的位置

  8. 怎么不见heap_no值为0和1的记录呢？MySQL会自动给每个页里加两条记录，由于这两个记录并不是我们字节插入的，所以有时候也称为伪记录 或虚拟记录。这两个伪记录一个代表最小记录，一个代表最大记录。最小记录和最大记录的heap_no值分别是0和1，也就是说它们的位置最靠前

  9. n_owned：页目录中每个组中最后一条记录的头信息中会存储该组一共有多少条记录，作为 n_owned 字段

  10. next_record：记录头信息里该属性非常重要，它表示从当前记录的真实数据到下一条记录的真实数据的地址偏移量

    1. 比如：第一条记录的next_record值为32，意味着从第一条记录的真实数据地址处向后找32个字节便是下一条记录的真实数据
    2. 注意：下一条记录指的并不是按照我们插入顺序的下一条记录，而是按照主键值由小到大的顺序的下一条记录。而且规定Infimum记录（也就是最小记录）的下一条记录就是本页中主键值最小的用户记录，而本页中主键值最大的用户记录的下一条记录就是Supremum记录（也就是最大记录）

3.2.4记录的真实数据

  1. 记录的真实数据除了我们自己定义的列的数据以外，还会有三个隐藏的列：

    列名 是否必须 占用空间 描述
    row_id 否 6字节 行ID，唯一标识一条记录
    transaction_id 是 6字节 事务ID
    roll_pointer 是 7字节 回滚指针

  2. 实际上这几个列的真正名称是：DB_ROW_ID、DB_TRX_ID、DB_ROLL_PTR

    1. 一个表没有手动定义主键，会选取一个Unique键作为主键，如果连Unique键都没有定义的话，则会为表默认添加一个名为row_id的隐藏列作为主键。所以row_id是在没有自定义主键以及Unique键的情况下才会存在的
    2. 事务ID和回滚指针在后面的章节中讲解

  3. 分析

    sql 复制代码 
    CREATE TABLE mytest(
col1 VARCHAR(10),
col2 VARCHAR(10),
col3 CHAR(10),
col4 VARCHAR(10)
)ENGINE=INNODB CHARSET=LATIN1 ROW_FORMAT=COMPACT;
 
 
INSERT INTO mytest
VALUES('a','bb','bb','ccc');
 
INSERT INTO mytest
VALUES('d',NULL,NULL,'fff');

    1. 第一条插入语句：

      sql 复制代码 
      03 02 01                     /*变长字段长度列表,逆序*/
00                           /*NULL标志位,第一行没有NULL值,用一个字节表示*/
00 00 10 00 2c               /*记录头信息,固定5字节长度*/
00 00 00 2b 68 00            /*RowID InnoDB自动创建,6字节*/
00 00 00 00 06 05            /*TransactionID*/
80 00 00 00 32 01 10         /*Roll Pointer*/
61                               /*列1数据'a'*/
62 62                            /*列2数据'bb'*/
62 62 20 20 20 20 20 20 20 20    /*列3数据'bb'*/
63 63 63                         /*列4数据'ccc'*/

    2. 第二条插入语句：

      sql 复制代码 
      03 01                               /*变长字段长度列表,逆序*/
06                                  /*NULL标志位,第三行有NULL值,用一个字节表示*/
00 00 20 ff 98                      /*Record Header*/
00 00 00 2b 68 02                   /*RowID*/
00 00 00 00 06 07                   /*TransactionID*/
80 00 00 00 32 01 10                /*Roll Pointer*/
64                                  /*列1数据'd'*/
66 66 66                            /*列4数据'fff'*/

（3）Dynamic和Compressed行格式

3.3.1行溢出

  1. InnoDB存储引擎可以将一条记录中的某些数据存储在真正的数据页面之外
  2. 注意：VARCHAR(M)中，M是指可以存放多少个字符。而一个VARCHAR(M)类型的列就最多可以存储65533个字节。如果我们给表指定，字符集是ASCII，ASCII中一个字符对应一个字节，因此它可以存放65535个字符。如果我们给表指定，字符集是utf8，utf8中一个汉字对应三个字节，因此它可以存放21845个字节
  3. 但是：
  4. 这样可以创建（65532+2个字节的变长字段的长度+1NULL值标识）：
  5. 或者将它设置为NOT NULL：
  6. 我们可以知道一个页的大小一般是16KB，也就是16384字节，而一个VARCHAR(M)类型的列就最多可以存储65533个字节，这样就可能出现一个页存放不了一条记录，这种现象称为行溢出
  7. 在Compact和Reduntant行格式中，对于占用存储空间非常大的列，在记录的真实数据处只会存储该列的一部分数据，把剩余的数据分散存储在几个其他的页中进行分页存储，然后记录的真实数据处用20个字节存储指向这些页的地址（当然这20个字节中还包括这些分散在其他页面中的数据的占用的字节数），从而可以找到剩余数据所在的页。这称为页的扩展

3.3.2Dynamic和Compressed行格式

  1. 在MySQL8.0中，默认行格式就是Dynamic，Dynamic、Compressed行格式和Compact行格式挺像，只不过在处理行溢出数据时有分歧
  2. Compressed和Dynamic两种记录格式对于存放在BLOB中的数据采用了完全的行溢出的方式。如图，在数据页中只存放20个字节的指针（溢出页的地址），实际的数据都存放在Off Page（溢出页）中
  3. Compact和Redundant两种格式会在记录的真实数据处存储一部分数据（存放768个前缀字节）

四、区、段和碎片区

（1）为什么要有区？

  1. B+树的每一层中的页都形成一个双向链表，如果是页为单位来分配存储空间的话，双向链表相邻的两个页之间的物理距离可能离得非常远。我们介绍B+树索引的使用场景的时候特别提到范围查询只需要定位到最左边的记录和最右边的记录，然后沿着双向链表一直扫描就可以了，而如果链表中相邻的两个页物理位置离得非常远，就是所谓的随机I/O（寻道...）。再一次强调，磁盘的速度和内存的速度差了好几个数量级，随机I/O是非常慢的，所以我们应该尽量让链表中相邻的页的物理位置也相邻，这样进行范围查询的时候才可以使用所谓的顺序I/O
  2. 引入区的概念，一个区就是物理位置上连续的64个页。因为InnoDB中的页的大小默认是16KB，所以一个区的大小是64*16KB=1MB。在表中数据量大的时候，为某个索引分配空间的时候就不再按照页的单位分配了，而是按照区为单位分配，甚至在表中的数据特别多的时候，可以一次性分配多个连续的区。虽然可能造成一点点空间的浪费（数据不足以填充满整个区），但是从性能角度看，可以消除很多的随机I/O，功大于过

（2）为什么要有段？

  1. 对于范围查询，其实是对B+树叶子节点中的记录进行顺序扫描，而如果不区分叶子节点和非叶子节点，统统把节点代表的页面放到申请到的区中的话，进行范围扫描的效果就大打折扣了。所以InnoDB对B+树的叶子节点和非叶子节点进行了区别对待，也就是说叶子节点有自己独有的区，非叶子节点也有自己独有的区。存放叶子节点的区的集合就算是一个段（Segment），存放非叶子节点的区的集合也算是一个段（Segment）。也就是说一个索引会生成2个段，一个叶子节点段，一个非叶子节点段
  2. 除了索引的叶子节点段和非叶子节点段之外，InnoDB中还有为存储一些特殊的数据而定义的段，比如回滚段。所以，常见的段有数据段、索引段、回滚段。数据段即为B+树的叶子节点，索引段即为B+树的非叶子节点
  3. 在InnoDB存储引擎中，对段的管理都是由引擎自身所完成，DBA不能也没有必要对其进行控制。这从一定程度上简化了DBA对于段的管理
  4. 段其实不对应表空间中的某一个连续的物理区域，而是一个逻辑上的概念，由若干个零散的页面（看下面为什么要有碎片区）以及一些完整的区组成

（3）为什么要有碎片区？

  1. 默认情况下，一个使用InnoDB存储引擎的表只有一个聚簇索引，一个索引会生成2个段（数据段和索引段），而段是以区为单位申请存储空间的，一个区默认占用1M（64*16KB=1024KB）存储空间，所以**默认情况下一个只存在几条记录的小表也需要2M的存储空间么？**以后每次添加一个索引都要多申请2M的存储空间么？这对于存储记录比较少的表简直是天大的浪费。这个问题的症结在于到现在为止我们介绍的区都是非常纯粹，也就是一个区被整个分配给某一个段，或者说区中的所有页面都是为了存储同一个段的数据而存在的，即使段的数据填不满区中所有的页面，那余下的页面也不能挪作他用
  2. 为了考虑以完整的区为单位分配给某个段对于数据量较小的表太浪费存储空间的这种情况，InnoDB提出了一个碎片区（fragment）的概念。在一个碎片区中，并不是所有的页都是为了存储同一个段的数据而存在的，而是碎片区中的页可以用于不同的目的，比如有些页面用于段A，有些页面用于段B，有些页甚至哪个段都不属于。碎片区直属于表空间，并不属于任何一个段
  3. 所以此后为某个段分配存储空间的策略是这样的：
    1. 在刚开始向表中插入数据的时候，段是从某个碎片区以单个页面为单位来分配存储空间的。
    2. 当某个段已经占用了32个碎片区页面之后，就会申请以完整的区为单位来分配存储空间。
  4. 所以现在段不能仅定义为是某些区的集合，更精确的应该是某些零散的页面以及一些完整的区的集合

（4）区的分类

  1. 区大体上可以分为4种类型：
    1. 空闲的区（FREE）：现在还没有用到这个区中的任何页面
    2. 有剩余空间的碎片区（FREE_FRAG）：表示碎片区中还有可用的页面
    3. 没有剩余空间的碎片区（FULL_FRAG）：表示碎片去中的所有页面都被使用，没有空闲页面
    4. 附属于某个段的区（FSEG）：每一个索引都可以分为叶子节点段和非叶子节点段
  2. 处于FREE、FREE_FRAG以及FULL_FRAG这三种状态的区都是独立的，直属于表空间。而处于FSEG状态的区是附属于某个段的

五、表空间

表空间可以看做是InnoDB存储引擎逻辑结构的最高层，所有的数据都存放在表空间中

表空间是一个逻辑容器，表空间存储的对象是段，在一个表空间中可以有一个或多个段，但是一个段只能属于一个表空间。表空间数据库由一个或多个表空间组成，表空间从管理上可以划分为系统表空间(System tablespace)、独立表空间(File-per-table tablespace)、撤销表空间(Undo Tablespace)和临时表空间(Temporary Tablespace）等

（1）独立表空间

  1. 独立表空间，即每张表有一个独立的表空间，也就是数据和索引信息都会保存在自己的表空间中。独立的表空间(即:单表)可以在不同的数据库之间进行迁移
  2. 空间可以回收（DROP TABLE 操作可自动回收表空间；其他情况，表空间不能自己回收)。如果对于统计分析或是日志表，删除大量数据后可以通过: alter table TableName engine=innodb;回收不用的空间。对于使用独立表空间的表，不管怎么删除，表空间的碎片不会太严重的影响性能，而且还有机会处理
  3. 独立表空间结构：独立表空间由段、区、页组成
  4. 真实表空间对应的文件大小：我们到数据目录里看，会发现一个新建的表对应的.ibd文件只占用了96KB，才6个页面的大小（MySQL5.7中），这是因为一开始表空间占用的空间很小，因为表里边都没有数据。不过别忘了这些.ibd文件是自扩展的，随着表中数据的增多，表空间对应的文件页逐渐增大。（先随便创建一张表，然后进/var/lib/mysql里查看，98304/1024=96）
  5. 在MySQL8.0中是7个页的大小，因为它把.frm文件合并到.ibd文件中了（114688/1024=112）
  6. 查看InnoDB的表空间类型（ON表示，每张表都会单独保存为一个.ibd文件）：

（2）系统表空间

  1. 系统表空间结构和独立表空间基本类似，只不过由于整个MySQL进程只有一个系统表空间，在系统表空间中会额外记录一些有关整个系统信息的页面，这部分是独立表空间中没有的
  2. InnoDB数据字典
    1. 当我们向一个表中插入一条记录的时候，MySQL校验过程如下：
    2. 先要校验一下插入语句对应的表存不存在，插入的列和表中的列是否符合，如果语法没有问题的话，还需要直到该表的聚簇索引和所有二级索引对应的根页面是哪个表空间的哪个页面，然后把记录插入到对应索引的B+树中。所以说，MySQL除了保存着我们插入的用户数据之外，还要保存许多额外的信息，比方说：（1）某个表属于哪个表空间，表里边有多少列（2）表对应的每一个列的类型是什么（3）该表有多少索引，每个索引对应哪几个字段，该索引对应的根页面在哪个表空间的哪个页面（4）该表有哪些外键，外键对应哪个表的哪些列（5）某个表空间对应文件系统上文件路径是什么（6）...
  3. 上述这些数据并不是我们使用insert语句插入的用户数据，实际上是为了更好地管理我们这些用户数据而不得已引入的额外数据，这些数据也称为元数据。InnoDB存储引擎特意定义了一些列的内部系统表（internal system table）来记录这些元数据
  4. 这些系统表也被称为数据字典，它们都是以B+树的形式保存在系统表空间的某些页面中，其中SYS_TABLES、SYS_COLUMNS、SYS_INDEXES、SYS_FIELDS这四个表尤其重要，称之为基本系统表（basic systemn tables）
  5. 我们先看看这四个表的结构：
  6. 注意：用户是不能直接访问InnoDB的这些内部系统表，除非你直接去解析系统表空间对应文件系统上的文件。不过考虑到查看这些表的内容可能有助于大家分析问题，所以在系统数据库information_schema中提供了一些以innodb_sys开头的表：
  7. 在information_schema数据库中的这些以innodb_sys开头的表并不是真正的系统内部表（内部系统表就是我们上边以SYS开头的那些表)，而是在存储引擎启动时读取这些以SYS开头的系统表，然后填充到这些以innodb_sys开头的表中，以INNODB_SYS开头的表和以SYS开头的表中的字段并不完全一样，但供大家参考已经足矣

六、附录：数据页加载的三种方式

  1. InnoDB从磁盘中读取数据的最小单位是数据页。而你想得到的id = xxx的数据，就是这个数据页众多行中的一行。对于MySQL存放的数据，逻辑概念上我们称之为表，在磁盘等物理层面而言是按数据页的形式进行存放的，当其加载到MySQL中我们称之为缓存页
  2. 如果缓冲池中没有该页数据，那么缓冲池有以下三种读取数据的方式，每种方式的读取效率都是不同的：
  3. 方式一：内存读取，如果该数据存在于内存中，基本上执行时间在1ms左右，效率还是很高的
  4. 方式二：随机读取，如果数据没有在内存中，就需要在磁盘上对该页进行查找，整体时间预估在10ms左右，这10ms中有6ms是磁盘的实际繁忙时间(包括了寻道和半圈旋转时间），有3ms是对可能发生的排队时间的估计值，另外还有1ms的传输时间，将页从磁盘服务器缓冲区传输到数据库缓冲区中。这10ms看起来很快，但实际上对于数据库来说消耗的时间已经非常长了，因为这还只是一个页的读取时间
  5. 方式三：顺序读取，顺序读取其实是一种批量读取的方式，因为我们请求的数据在磁盘上往往都是相邻存储的，顺序读取可以帮我们批量读取页面，这样的话，一次性加载到缓冲池中就不需要再对其他页面单独进行磁盘I/O操作了。如果一个磁盘的吞吐量是40MB/S，那么对于一个16KB大小的页来说，一次可以顺序读取2560 (40MB/16KB)个页，相当于一个页的读取时间为0.4ms。采用批量读取的方式，即使是从磁盘上进行读取，效率也比从内存中只单独读取一个页的效率要高
相关推荐
若兰幽竹7 分钟前
【从零开始编写数据库：基于Python语言实现数据库ToyDB的ACID特性】
数据库·python
宇钶宇夕9 分钟前
S7-200 SMART CPU 密码清除全指南：从已知密码到忘记密码的解决方法
运维·服务器·数据库·程序人生·自动化
周杰伦的稻香18 分钟前
MySQL密码管理器“mysql_config_editor“
数据库·mysql
云朵大王22 分钟前
SQL 视图与事务知识点详解及练习题
java·大数据·数据库
czhc11400756631 小时前
LINUX712 MYSQL；磁盘分区；NFS
数据库·mysql·adb
叁沐1 小时前
MySQL 13 为什么表数据删掉一半，表文件大小不变？
mysql
不太可爱的大白2 小时前
Mysql:分库分表
数据库·mysql
四季豆豆豆2 小时前
博客项目 laravel vue mysql 第四章 分类功能
vue.js·mysql·laravel
十五年专注C++开发2 小时前
hiredis: 一个轻量级、高性能的 C 语言 Redis 客户端库
开发语言·数据库·c++·redis·缓存
憨堡包^—^2 小时前
Docker —— MySQL主从复制集群
mysql·docker·容器
热门推荐
01KGG转MP3工具|非KGM文件|解密音频02集群聊天服务器---MySQL数据库的建立03Coze扣子平台完整体验和实践（附国内和国际版对比）04绿色建筑新态势：楼宇自控助力能效提升，推动成本优化新路径05使用Ruby接入实时行情API教程06扣子（coze）实战|我用扣子搭建了一个自动分析小红薯笔记内容的AI应用|详细步骤拆解07【无标题】08基于odoo17的设计模式详解---单例模式09DeepSeek各版本说明与优缺点分析10全球最强模型Grok4，国内已可免费使用！（附教程）