大学生做网站赚钱,建设网站涉及哪些问题,网站程序更换,网站图片模板源码6. InnoDB 引擎底层解析
MySQL 对于我们来说还是一个黑盒#xff0c;我们只负责使用客户端发送请求并等待服务器返回结果#xff0c;表中的数据到底存到了哪里#xff1f;以什么格式存放的#xff1f;MySQL 是以什么方式来访问的这些数据#xff1f;这些问题我们统统不知…6. InnoDB 引擎底层解析
MySQL 对于我们来说还是一个黑盒我们只负责使用客户端发送请求并等待服务器返回结果表中的数据到底存到了哪里以什么格式存放的MySQL 是以什么方式来访问的这些数据这些问题我们统统不知道。要搞明白查询优化背后的原理就必须深入 MySQL 的底层去一探究竟而且事务、锁等的原理也要求我们必须深入底层。
6.1. InnoDB 记录存储结构和索引页结构
InnoDB 是一个将表中的数据存储到磁盘上的存储引擎所以即使关机后重启我们的数据还是存在的。而真正处理数据的过程是发生在内存中的所以需要把磁盘中的数据加载到内存中如果是处理写入或修改请求的话还需要把内存中的内容刷新到磁盘上。而我们知道读写磁盘的速度非常慢和内存读写差了几个数量级所以当我们想从表中获取某些记录时InnoDB 存储引擎需要一条一条的把记录从磁盘上读出来么
InnoDB 采取的方式是将数据划分为若干个页以页作为磁盘和内存之间交互的基本单位InnoDB 中页的大小一般为 16 KB。也就是在一般情况下一次最少从磁盘中读取 16KB 的内容到内存中一次最少把内存中的 16KB 内容刷新到磁盘中。
我们平时是以记录为单位来向表中插入数据的这些记录在磁盘上的存放方式也被称为行格式或者记录格式。InnoDB 存储引擎设计了 4 种不同类型的行格式分别是 Compact、Redundant、Dynamic 和 Compressed 行格式。
6.1.1. 行格式
我们可以在创建或修改表的语句中指定行格式 CREATE TABLE 表名 (列的信息) ROW_FORMAT行格式名称
6.1.1.1. COMPACT 我们知道 MySQL 支持一些变长的数据类型比如 VARCHAR(M)、 VARBINARY(M)、各种 TEXT 类型各种 BLOB 类型我们也可以把拥有这些数据类型的列称为变长字段变长字段中存储多少字节的数据是不固定的所以我们在存储真实数据的时候需要顺便把这些数据占用的字节数也存起来。如果该可变字段允许存储的最大字节数M×W超过 255 字节并且真实存储的字节数L超过 127 字节则使用 2 个字节否则使用 1 个字节。
表中的某些列可能存储 NULL 值如果把这些 NULL 值都放到记录的真实数据中存储会很占地方所以 Compact 行格式把这些值为 NULL 的列统一管理起来存储到 NULL 值列表。每个允许存储 NULL 的列对应一个二进制位二进制位的值为 1 时代表该列的值为 NULL。二进制位的值为 0 时代表该列的值不为 NULL。
还有一个用于描述记录的记录头信息它是由固定的 5 个字节组成。5 个字节也就是 40 个二进制位不同的位代表不同的意思。
预留位 1 1 没有使用 预留位 2 1 没有使用
delete_mask 1 标记该记录是否被删除min_rec_mask 1 B树的每层非叶子节点中的最小记录都会添加该标记n_owned 4 表示当前记录拥有的记录数heap_no 13 表示当前记录在页的位置信息record_type3 表示当前记录的类型0 表示普通记录1 表示 B树非叶子节点记录2 表示最小记录3 表示最大记录next_record16 表示下一条记录的相对位置 记录的真实数据除了我们自己定义的列的数据以外MySQL 会为每个记录默认的添加一些列也称为隐藏列包括 DB_ROW_ID(row_id)非必须6 字节表示行 ID唯一标识一条记录 DB_TRX_ID必须6 字节表示事务 ID DB_ROLL_PTR必须7 字节表示回滚指针
InnoDB 表对主键的生成策略是优先使用用户自定义主键作为主键如果用户没有定义主键则选取一个 Unique 键作为主键如果表中连 Unique 键都没有定义的话则 InnoDB 会为表默认添加一个名为 row_id 的隐藏列作为主键。 DB_TRX_ID也可以称为 trx_id 和 DB_ROLL_PTR也可以称为 roll_ptr 这两个列是必有的但是 row_id 是可选的在没有自定义主键以及 Unique 键的情况下才会添加该列。 其他的行格式和 Compact 行格式差别不大。
6.1.1.2. Redundant 行格式
Redundant 行格式是 MySQL5.0 之前用的一种行格式不予深究。
6.1.1.3. Dynamic 和 Compressed 行格式
MySQL5.7 的默认行格式就是 DynamicDynamic 和 Compressed 行格式和Compact 行格式挺像只不过在处理行溢出数据时有所不同。Compressed 行格式和 Dynamic 不同的一点是Compressed 行格式会采用压缩算法对页面进行压缩以节省空间。
6.1.1.4. 数据溢出
如果我们定义一个表表中只有一个 VARCHAR 字段如下 CREATE TABLE test_varchar( c VARCHAR(60000) ) 然后往这个字段插入 60000 个字符会发生什么
前边说过MySQL 中磁盘和内存交互的基本单位是页也就是说 MySQL 是以页为基本单位来管理存储空间的我们的记录都会被分配到某个页中存储。而一个页的大小一般是 16KB也就是 16384 字节而一个 VARCHAR(M)类型的列就最多可以存储 65532 个字节这样就可能造成一个页存放不了一条记录的情况。
在 Compact 和 Redundant 行格式中对于占用存储空间非常大的列在记录的真实数据处只会存储该列的该列的前 768 个字节的数据然后把剩余的数据分散存储在几个其他的页中记录的真实数据处用 20 个字节存储指向这些页的地址。这个过程也叫做行溢出存储超出 768 字节的那些页面也被称为溢出页。
Dynamic 和 Compressed 行格式不会在记录的真实数据处存储字段真实数据的前 768 个字节而是把所有的字节都存储到其他页面中只在记录的真实数据处存储其他页面的地址。
那发生行溢出的临界点是什么呢也就是说在列存储多少字节的数据时就 会发生行溢出 MySQL 中规定一个页中至少存放两行记录以上边的 test_varchar 表为例它只有一个列 c我们往这个表中插入两条记录每条记录最少插入多少字节的数据才会行溢出的现象呢这得分析一下页中的空间都是如何利用的。 每个页除了存放我们的记录以外也需要存储一些页本身的信息加起来需要 132 个字节的空间其他的空间都可以被用来存储记录。每个记录需要的额外信息是 27 字节。
假设一个列中存储的数据字节数为 nMySQL 规定如果该列不发生溢出的现 象就需要满足下边这个式子 132 2×(27 n) 16384 求解这个式子得出的解是n 8099。也就是说如果一个列中存储的数据小于 8099 个字节那么该列就不会成为溢出列否则该列就需要成为溢出列。不过这个 8099 个字节的结论只是针对只有一个列的 test_varchar 表来说的如果表中有多个列那上边的式子和结论都需要改。所以重点就是这个临界点具体值无关紧要只要知道如果我们一条记录的某个列中存储的数据占用的字节数非常多时该列就可能成为溢出列。
6.1.2. 索引页格式
前边我们简单提了一下页的概念它是 InnoDB 管理存储空间的基本单位一个页的大小一般是 16KB。 InnoDB 为了不同的目的而设计了许多种不同类型的页存放我们表中记录的那种类型的页自然也是其中的一员官方称这种存放记录的页为索引INDEX页不过要理解成数据页也没问题毕竟存在着聚簇索引这种索引和数据混合的东西。
6.1.2.1. 数据页结构 一个 InnoDB 数据页的存储空间大致被划分成了 7 个部分
File Header 文件头部 38 字节 页的一些通用信息Page Header 页面头部 56 字节 数据页专有的一些信息Infimum Supremum 最小记录和最大记录 26 字节 两个虚拟的行记录User Records 用户记录 大小不确定 实际存储的行记录内容Free Space 空闲空间 大小不确定 页中尚未使用的空间Page Directory 页面目录 大小不确定 页中的某些记录的相对位置File Trailer 文件尾部 8 字节 校验页是否完整 User Records 我们自己存储的记录会按照我们指定的行格式存储到 User Records 部分。但是在一开始生成页的时候其实并没有 User Records 这个部分每当我们插入一条记录都会从 Free Space 部分也就是尚未使用的存储空间中申请一个记录大小的空间划分到 User Records 部分当 Free Space 部分的空间全部被 User Records部分替代掉之后也就意味着这个页使用完了如果还有新的记录插入的话就需要去申请新的页了。
当前记录被删除时则会修改记录头信息中的 delete_mask 为 1也就是说被删除的记录还在页中还在真实的磁盘上。这些被删除的记录之所以不立即从磁盘上移除是因为移除它们之后把其他的记录在磁盘上重新排列需要性能消耗。 所以只是打一个删除标记而已所有被删除掉的记录都会组成一个所谓的垃圾链表在这个链表中的记录占用的空间称之为所谓的可重用空间之后如果有新记录插入到表中的话可能把这些被删除的记录占用的存储空间覆盖掉。
同时我们插入的记录在会记录自己在本页中的位置写入了记录头信息中heap_no 部分。heap_no 值为 0 和 1 的记录是 InnoDB 自动给每个页增加的两个记录称为伪记录或者虚拟记录。这两个伪记录一个代表最小记录一个代表最大记录这两条存放在页的 User Records 部分他们被单独放在一个称为 Infimum Supremum 的部分。
记录头信息中 next_record 记录了从当前记录的真实数据到下一条记录的真实数据的地址偏移量。这其实是个链表可以通过一条记录找到它的下一条记录。 但是需要注意注意再注意的一点是下一条记录指得并不是按照我们插入顺序的下一条记录而是按照主键值由小到大的顺序的下一条记录。而且规定 Infimum记录也就是最小记录 的下一条记录就是本页中主键值最小的用户记录而本页中主键值最大的用户记录的下一条记录就是 Supremum 记录也就是最大记录。 我们的记录按照主键从小到大的顺序形成了一个单链表记录被删除则从这个链表上摘除。 Page Directory Page Directory 主要是解决记录链表的查找问题。如果我们想根据主键值查找页中的某条记录该咋办按链表查找的办法从 Infimum 记录最小记录开始沿着链表一直往后找总会找到或者找不到。
InnoDB 的改进是为页中的记录再制作了一个目录他们的制作过程是这样的 1、将所有正常的记录包括最大和最小记录不包括标记为已删除的记录划分为几个组。 2、每个组的最后一条记录也就是组内最大的那条记录的头信息中的n_owned 属性表示该记录拥有多少条记录也就是该组内共有几条记录。 3、将每个组的最后一条记录的地址偏移量单独提取出来按顺序存储到靠近页的尾部的地方这个地方就是所谓的 Page Directory也就是页目录页面目录中的这些地址偏移量被称为槽英文名Slot所以这个页面目录就是由槽组成的。 4、每个分组中的记录条数是有规定的对于最小记录所在的分组只能有 1条记录最大记录所在的分组拥有的记录条数只能在 1~8 条之间剩下的分组中记录的条数范围只能在是 4~8 条之间。如下图 这样一个数据页中查找指定主键值的记录的过程分为两步 通过二分法确定该记录所在的槽并找到该槽所在分组中主键值最小的那条记录。 通过记录的 next_record 属性遍历该槽所在的组中的各个记录。 Page Header InnoDB 为了能得到一个数据页中存储的记录的状态信息比如本页中已经存储了多少条记录第一条记录的地址是什么页目录中存储了多少个槽等等 特意在页中定义了一个叫 Page Header 的部分它是页结构的第二部分这个部分占用固定的 56 个字节专门存储各种状态信息。 File Header File Header 针对各种类型的页都通用也就是说不同类型的页都会以 File Header 作为第一个组成部分它描述了一些针对各种页都通用的一些信息比方说页的类型这个页的编号是多少它的上一个页、下一个页是谁页的校验和等等这个部分占用固定的 38 个字节。 页的类型包括 Undo 日志页、段信息节点、Insert Buffer 空闲列表、Insert Buffer 位图、系统页、事务系统数据、表空间头部信息、扩展描述页、溢出页、 索引页有些页会在后面的课程看到。 同时通过上一个页、下一个页建立一个双向链表把许许多多的页就串联起来而无需这些页在物理上真正连着。但是并不是所有类型的页都有上一个和下一个页的属性数据页是有这两个属性的所以所有的数据页其实是一个双向链表。 File Trailer 我们知道 InnoDB 存储引擎会把数据存储到磁盘上但是磁盘速度太慢需要以页为单位把数据加载到内存中处理如果该页中的数据在内存中被修改了 那么在修改后的某个时间需要把数据同步到磁盘中。但是在同步了一半的时候中断电了咋办 为了检测一个页是否完整也就是在同步的时候有没有发生只同步一半的尴尬情况InnoDB 每个页的尾部都加了一个 File Trailer 部分这个部分由 8 个字节组成可以分成 2 个小部分
前 4 个字节代表页的校验和 这个部分是和 File Header 中的校验和相对应的。每当一个页面在内存中修改了在同步之前就要把它的校验和算出来因为 File Header 在页面的前边 所以校验和会被首先同步到磁盘当完全写完时校验和也会被写到页的尾部如果完全同步成功则页的首部和尾部的校验和应该是一致的。如果写了一半儿断电了那么在 File Header 中的校验和就代表着已经修改过的页而在 File Trailer 中的校验和代表着原先的页二者不同则意味着同步中间出了错。
后 4 个字节代表页面被最后修改时对应的日志序列位置LSN这个也和校验页的完整性有关。 这个 File Trailer 与 File Header 类似都是所有类型的页通用的
