1. InnoDB是干嘛的?

InnoDB是一个将表中的数据存储到磁盘上的存储引擎。
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能。
项目地址:https://github.com/YunaiV/ruoyi-vue-pro

2. InnoDB是如何读写数据的?

InnoDB处理数据的过程是发生在内存中的,需要把磁盘中的数据加载到内存中,如果是处理写入或修改请求的话,还需要把内存中的内容刷新到磁盘上。
读写磁盘的速度非常慢,和内存读写差了几个数量级,所以当我们想从表中获取某些记录时,InnoDB存储引擎将数据划分为若干个页,以页作为磁盘和内存之间交互的基本单位,InnoDB中页的大小默认为 16 KB。也就是在一般情况下,一次最少从磁盘中读取16KB的内容到内存中,或者一次最少把内存中的16KB内容刷新到磁盘中。
所以当你用postman测试一个分页查询接口时,发现第一次打印耗时300 ~ 400ms,往后不停的查找下一页都是30 ~ 40ms,原因就是第一次请求接口时,读数据库的时候需要读磁盘,从磁盘加载16KB的数据到内存,往后下一页的数据都是从内存中获取,没有再读磁盘,除非在内存中的16KB的数据中找不到,才会再次读磁盘获取下一个16KB的数据到内存中。
我们不讨论mysql 8.0舍弃的查询缓存特性,我测试过mysql 5.7中关闭了查询缓存,也仍然是第一次慢,后续查询很快,查询时间相差大概10倍的样子
温馨提示:分页查询和数据库的一页16KB中的"页"是两个概念。
注意:innodb_page_size变量在服务器运行过程中不可以更改,只能在第一次初始化MySQL数据目录时指定。所以页在运行时的大小不可更改。
基于微服务的思想,构建在 B2C 电商场景下的项目实战。核心技术栈,是 Spring Boot + Dubbo 。未来,会重构成 Spring Cloud Alibaba 。
项目地址:https://github.com/YunaiV/onemall

3. varchar疑问千千万——InnoDB行格式

看到这里,你一定有着和我相同的疑问,比如varchar(255)后面这个最大长度应该怎么选择呢?为什么不能varchar(65535)而最大只能varchar(16383)呢?我来带你看!
我们平时是以记录为单位来向表中插入数据的,这些记录在磁盘上的存放方式也被称为行格式或者记录格式。行格式有4种,分别是Dynamic、Compact、Redundant和Compressed
MySQL 5+默认行格式都是Dynamic, 在MySQL 5 和 MySQL 8经过验证确实是的。
SHOWVARIABLESLIKE"innodb_default_row_format"
大家在业务中和平时使用中都几乎没有修改过或者注意过InnoDB行格式,那么我就只重点讲默认行格式dynamic,让大家更深层次理解平时开发中的varchar。
请记住这个表结构,后面会围绕这个来讲
CREATETABLEtest
 ( 

c1 
VARCHAR
(
10
), 

c2 
VARCHAR
(
10
NOTNULL

c3 
CHAR
(
10
), 

c4 
VARCHAR
(
10
)) 
CHARSET
 = utf8mb4;

现在业务数据库字符集都是utf8mb4,我就以这个来讲,把理解难度降到最低。
INSERTINTOtest
 ( c1, c2, c3, c4 )

VALUES
(
'aaaa'
'你好啊'
'cc'
'd'
),(
'eeee'
'fff'
NULL
NULL
);

现在,表中的记录就是这样

3.1 dynamic——innodb默认行格式

关于记录的额外信息这部分,是服务器为了描述这条记录而不得不额外添加的一些信息,这些额外信息分为3类,分别是变长字段长度列表、NULL值列表和记录头信息。
在这里我只讲变长字段长度列表、NULL值列表。因为记录头信息非常的绕和本篇没多大关系。

3.2 innodb怎么知道varchar真正有多长?——变长字段长度列表

一些变长的数据类型,比如VARCHAR(M)、各种TEXT类型,各种BLOB类型,变长数据类型的字段中存储多少字节的数据是不固定的,在存储真实数据的时候需要把这些数据占用的字节数也存起来。
就像设计String类型,不仅仅是存放真实数据的char数组,还有length变量去记录字符串长度。又比如input输入框最大限制500字,但是你还得有一个变量去统计真实在输入框内有多少字符。同理,varchar也有记录真实数据长度的变量(假设为L,后文沿用方便描述),L表示varchar真实占用的字节数,innodb最多分配2个字节去表示这个L,就像unsigned short类型,2个字节,寄存器最多只有16位来让你存这个长度,所以L记录范围是2^16 - 1 = 65535
这些变长字段(比如varchar)占用的存储空间分为两部分:
  • 真正的数据内容部分,放在对应的列
  • 真实占用的字节数,放在变长字段列表部分
我们拿test表中的第一条记录来举个例子。因为test表的c1、c2、c4列都是VARCHAR(10)类型的,说明最大10个字符,所以这三个列的值的长度都需要保存在记录开头处,因为test表中的各个列都使用的是utf8mb4字符集,每个字符最大需要4个字节来进行编码(不使用utf8而是utf8mb4是因为可能存储emoji表情,如果只是文字,utf8就足够),来看一下第一条记录各变长字段内容的长度:
怎么确定这些字段有多少字节?
比如这里c2的"你好啊",使用如下sql可以确定
SELECTLENGTH
(c2) 
fromtestwhere
 c1=
'aaaa'
;

各变长字段数据占用的字节数按照列的顺序逆序存放!!
由于第一行记录中c1、c2、c4列中的字符串都比较短,也就是说varchar真实占用的字节数比较小,L用1个字节(8个bit位) 就可以表示,但是如果varchar真实占用的字节数比较多,L可能就需要用2个字节(16个bit位) 来表示。到底varchar能存多少字节呢?继续往下看。

3.3 varchar(M) 能存多少个字符,为什么提示最大16383?

首先要理解varchar(M)的M是说字符个数,而不是字节。
为什么不能varchar(20000)之类的,是20000个字符放不下吗?
为什么提示只能最大16383个字符呢?这个数字是怎么算出来的?
这个我就得和你好好唠嗑了!
varchar是变长的,varchar(64) 能存放0~64个字符不等,并不一定是存了最大64个字符,谁知道这个类型到底存了几个字符呢?
innodb设计的时候,就已经考虑到了,不过是用字节作为单位,后续我们可以根据对应字符集转变为字符来理解,innodb必须记录变长字段varchar真实占用的字节数L。前面说过了,innodb最多分配2个字节(16个bit位)的空间去记录这个L。
InnoDB有它的一套规则,我们引入W、M和L这几个符号:
  1. 假设某个字符集中最多需要W字节来表示一个字符
  • utf8mb4字符集中的W就是4
  • utf8字符集中W就是3
  • gbk字符集中的W就是2
  • ascii字符集中的W就是1。
  1. 对于变长类型VARCHAR(M)来说,这种类型表示能存储最多M个字符(注意是字符不是字节)
    所以这个类型能表示的字符串最多占用的字节数就是M × W。
  2. 假设它实际存储的字符串占用的字节数是L。
来看极限边界情况,innodb为了记录一下varchar真实存储多少个字节,最多分配2个字节的空间去记录,2个字节16个比特位,全部为1,最大能记录的数字是2^16-1是65535个,innodb最大能记录varchar占用的字节数就是65535个,utf8mb4字符集一个字符是最大是4个字节,65535 / 4 = 16383.75,只要varchar字符数不超过16383个,innodb就可以记录真实占用的长度L,再多就记录不了了!所以就能解释刚刚的图了,varchar(20000)不行,最大也就16383个字符
但是!这里强调是有但是的!
行最大长度是65535字节,行里面有很多东西,包括变长字段列表、NULL值列表、记录头信息。你得考虑该字段如果允许为NULL,NULL值列表会占用一个字节(只要没超过8个字段),每一列字段的变长字段实际长度会花费1~2个字节,如果该字段的数据太大,会变成溢出列,该字段的数据会分成很多行存储(后面会讲,你可以看完NULL值列表和溢出列后再回来看这个例子)。所以即便提示16383个字符,你也绝对不可能存到16383。
我做了个测试
createtable
 t2 ( 
namevarchar
(
16383
))
charset
=utf8mb4;

不断往这个字段添加字符保存测试,最后发现,这些字符总长度到极限也就是48545字节。
如果超过就会报错
这里48545个字节,再多一个字符就会报错,远不到65535字节,差了1W多字节。主要是因为溢出列的原因,数据分散在不同的行中,所以,很长的数据,建议往text类型考虑。这个现象可以看出,varchar(M)的M很大,实际是达不到M这个边界值的。
下面说明一下规则(讲解中字符集用utf8mb4,W=4)
规则一:如果允许存储的最大字节数M × W <= 255,varchar占用的真实字节数L只分配1个字节来表示。
有人说,允许存储的最大字节数M × W <= 255,即允许存储的最大字符数 <= ⌊255 / 4⌋ = 63个时,varchar占用的真实字节数L仅分配1个字节就能表示。这个结论正确吗?
显然错误,因为这里255 / 4,你怎么知道每个存储的一个字符是4个字节呢?难道全部存的emoji表情?不存字母汉字啥的?
InnoDB在读记录的变长字段长度列表时先查看表结构,如果某个变长字段允许存储的最大字节数不大于255时,只用1个字节来表示真实数据占用的字节。
规则二:如果允许存储的最大字节数M × W > 255,则分为两种情况:
如果实际存储字节L <= 127,varchar占用的真实字节数L仅分配1个字节就能表示。(⌊ … ⌋表示向下取整)
有人说,实际存储字节L <= 127,即实际存储字符 <= ⌊127 / 4⌋ = 31个时,varchar占用的真实字节数L仅分配1个字节就能表示。这个结论正确吗?
显然错误,因为这里127 / 4,你怎么知道实际存储的一个字符是4个字节呢?难道全部存的emoji表情?不存字母汉字啥的?
如果实际存储字节L > 127,varchar占用的真实字节数L需要分配2个字节才能表示。
另外需要注意的是,变长字段列表只存储非NULL的列的长度。
表记录是这样的
对于第二条记录,c4列值为NULL,所以只存储c1和c2列即可。
第一条记录的变长字段长度列表部分占用3字节空间,因为有c1、c2、c4列,且内容都很少,每列真实占用字节数用1个字节可以表示,加起来就是3个字节,第二条记录变长字段长度列表部分占用2字节。
当然,并不是所有记录都有这个变长字段长度列表部分,比方说表中所有的列都不是变长的数据类型或者 所有列的值都是NULL 的话,这一部分就不需要有。实际业务开发中,几乎没有不使用varchar的,所以实际开发中的记录都会有变长字段长度列表部分

3.4 记录为NULL,innodb如何处理?——NULL值列表

能仔细看到这里,你肯定是个高手了。如果你和我一样开发规范中不推荐NULL,一般都写NOT NULL,其实记录中就不存在NULL值列表了,也节省了空间。
如果表中的某些列可能存储NULL值,把这些NULL值都放到记录的真实数据中存储会很占地方,所以dynamic行格式把这些值为NULL的列统一管理起来,存储到NULL值列表中,它的处理过程是这样的:
1.统计表中允许存储NULL的列有哪些。
主键列、被NOT NULL修饰的列都是不可以存储NULL值的,所以在统计的时候不会把这些列算进去。比方说表test的3个列c1、c3、c4都是允许存储NULL值的,而c2列是被NOT NULL修饰,不允许存储NULL值。
2.如果表中没有允许存储 NULL 的列,则 NULL值列表也不存在了,否则将每个允许存储NULL的列对应一个二进制位,二进制位按照列的顺序逆序排列。二进制位的值为1时,代表该列的值为NULL,为0时,代表该列的值不为NULL。因为表test的c1、c3、c4都是允许存储NULL值的允许为NULL的列,所以这3个列和二进制位的对应关系就是这样:
3.NULL值列表必须用整数个字节的位表示,如果使用的二进制位个数不是整数个字节,则在字节的高位补0。
也就是说,表test只有3个字段允许为NULL,对应3个二进制位,不足1字节,那么就在高位补0即可。
以此类推,如果表中有9个字段都允许为NULL,那么这个记录的NULL值列表就需要2个字节来表示,高字节高位补0。
对于第一条记录,c1、c3、c4都不为NULL,对应的为进制位为0,十六进制表示就是0x00
对于第二条记录,c3、c4都是NULL,对应的二进制位为1,十六进制表示就是0x06
这两条记录在填充了NULL值列表后示意图如下:

3.5 某个列数据占用的字节数非常多怎么办?——dynamic行格式的溢出列

如果某个列中存储的数据占用的字节数非常多,该列就可能称为溢出列。
对于占用存储空间非常多的列,在记录真实数据时,该列只会用20字节空间,而这20字节的空间不存储数据,因为数据都分散存储在其他几行中了。这20字节的空间存储的是分散行的地址和占用的字节数。分散行记录是单链表连接的结构。

后续

如果大家对innodb存储结构其他行格式感兴趣,或者我没说的记录头信息,可以去阅读《MySQL是怎样运行的》一书,我和书中不同的是,书中讲的Compact格式,字符集是ascii,我选用的是平时开发中用到的默认dynamic格式,字符集是utf8mb4,字符集变化后所有的数据我在文中和图中都有重新计算。大家平时或许没关注过行格式,那么就是按照dynamic格式理解就可以,更贴近实际开发。


欢迎加入我的知识星球,一起探讨架构,交流源码。加入方式,
长按下方二维码噢

已在知识星球更新源码解析如下:

最近更新《芋道 SpringBoot 2.X 入门》系列,已经 101 余篇,覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。
提供近 3W 行代码的 SpringBoot 示例,以及超 4W 行代码的电商微服务项目。
获取方式:点“在看”,关注公众号并回复 666 领取,更多内容陆续奉上。
文章有帮助的话,在看,转发吧。
谢谢支持哟 (*^__^*)
继续阅读
阅读原文