MySQL 记录、页、索引的数据结构简析

发布时间：2025-11-05 13:02:23 来源：创站工坊 作者：域名

引言

本文在介绍 MySQL 内存中记录、记据结页、录页索引、索引游标的构简数据结构的基础上，通过简单分析插入操作过程中行格式的记据结转换介绍了不同数据结构的关系，其中不涉及加锁相关逻辑。录页

原理

记录

InnoDB 存储引擎基于记录（record）存储，索引表明记录是构简根据行（row）格式存储。

MySQL 中有行格式有以下三种存储方式：

因此：

个人理解存取数据时完成二进制到“字符串”的相互转换（忽略其他数据类型），相当于客户端与服务端交互时的编码与解码。

内存中逻辑记录与其中的字段分别对应数据结构 dtuple_t 与 dfield_t。

结构体定义如下所示。

其中：

数据结构 dfield_t 中保存列的免费源码下载信息。

其中：

物理记录由 rec_t 数据结构表示，字节类型。

页

页和记录类似同样可以分为以下两种形式：

页分多种类型，比如 index page、undo log page 等，本文关注的是 index page。

由于 InnoDB 是索引组织树，索引即数据，b2b信息网因此可以将索引页理解为数据页。

InnoDB 中页是一个无序堆，因此页中的记录无序存放，记录间通过 record header 中的 next record 组成单向链表。

buffer pool 中与页相关的有两个数据结构，包括 buf_block_t 和 buf_page_t 。

buf_block_t 是数据页控制体的一种。

其中：

buf_page_t 称为数据页控制体。

其中：

索引

索引是基于以空间换时间的思想用于加速查询的数据结构。

InnoDB 中索引基于 B+ 树实现，因此每个索引都是一棵 B+ 树。索引用于组织页，页用于组织行记录。

每个 B+ 树索引在内存中对应数据结构 dict_index_t。

其中：

通过 B+ 树索引进行查找（lookup）是最为常见的操作，具体通过游标实现。

游标

游标是一个逻辑概念，无论是写入还是查询，都需要在 B+ 树上遍历至某个位置，具体到某个 block 上的某个 record。

InnoDB 中通过 cursor search 实现 B+ 树的查找，每个 open 一个 cursor 都会开启一个从 B+ 树 root 结点搜索到指定层级的 record 的搜索过程。

cursor 分为以下两种：

page cursor 在定位（lookup）到记录后，再通过查询模式（search mode）再进行向前或向后的记录扫描（scan）。

比如对于一个主键的范围查询，首先需要定位第一条记录，然后进行记录的顺序扫描。

InnoDB 中定义了四种查询模式：

插入操作的 search_mode 默认是 PAGE_CUR_LE，即插在最后一个小于等于该 dtuple 的 rec_t 后。

为了提高查询效率，InnoDB 做了以下优化：

B-tree cursor 对应 btr_cur_t 结构体。

其中：

page cursor 对应 page_cur_t 结构体。

其中：

persistent cursor 对应 btr_pcur_t 数据结构。

其中：

下面以 insert 语句的执行为例，分析不同数据结构之间的关系。

insert 语句

build_template

从 server 层调用存储引擎的接口 handler 开始，具体是 ha_innobase::write_row 函数。

其中：

unsigned char 数据类型经常被用于处理原始字节数据，比如在进行二进制文件读写、网络通信、处理图像数据、编码转换或者其他需要以字节为单位操作的场景中。利用 unsigned char 可以确保不会有负值出现，这在与二进制数据和位操作打交道时非常有用。

m_prebuilt 变量是 row_prebuilt_t 结构体指针类型，其中部分成员如下所示，包括表、索引、游标等各种信息。

其中：

row_prebuilt_t 结构体与 build_template 函数的作用参考 chatgpt：

在 InnoDB 存储引擎的设计中，row_prebuilt_t和build_template都是实现 SQL 层与存储引擎层之间高效数据交互的重要组成部分。一方面，row_prebuilt_t作为一个操作上下文，保存了完成某个表操作所需的所有信息；另一方面，build_template则通过预先构建模板来优化数据列的读取和转换过程。

byte -> dtuple_t* row

row_insert_for_mysql 函数中调用 row_insert_for_mysql_using_ins_graph 函数，其中将 Server 层的记录格式转换为 InnoDB 的记录格式，具体是从 byte 转换为 dtuple_t。

其中：

这里又出现了一个重要的结构体 ins_node_t，该结构体部分成员如下所示。

其中：

row_mysql_convert_row_to_innobase 函数中遍历索引的所有列（prebuilt->n_template）进行赋值。

其中：

其中：

其中：

到这里完整的行数据索引元组格式 dtuple_t* row dtuple_t 准备好了，但由于 InnoDB 是索引组织树，因此还需要将数据保存到索引元组格式 dtuple_t* entry 中。

dtuple_t* row -> dtuple_t* entry

row_ins_step 函数中创建 ins_node_t 并调用 row_ins 函数。

row_ins 函数中遍历表的每个 index，插入 index entry。

其中：

row_ins_index_entry_step 函数中向指定索引中插入记录。

其中：

其中：

到这里每个索引的数据也准备好了，但是还不知道数据插入的位置，理论上是插在最后一个小于等于该 dtuple 的 rec_t 后。

cursor

row_ins_index_entry 函数中以插入主键索引为例。

row_ins_clust_index_entry_low 函数中以乐观插入为例。

其中：

btr_pcur_open 函数中调用 btr_cur_search_to_nth_level 函数用于自顶向下查找整个 B-tree。

其中：

其中：

其中：

到这里就定位到了数据插入的位置，开始真正的数据插入。

dtuple_t* entry -> byte

调用 btr_cur_optimistic_insert 函数乐观插入。

其中：

page_cur_tuple_insert 函数中调用 rec_convert_dtuple_to_rec_new 函数将逻辑记录转换成物理记录。

相关文章