1. InnoDB是干嘛的？

InnoDB是一个将表中的数据存储到磁盘上的存储引擎。

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数据目录时指定。所以页在运行时的大小不可更改。

3. varchar疑难千千万——InnoDB行格局

❝

看到这里，你肯定有着和我雷同的疑难，比方varchar(255)前面这个最大长度应该怎么抉择呢？为什么不能varchar(65535)而最大只能varchar(16383)呢？我来带你看！

❞

咱们平时是以「记录」为单位来向表中插入数据的，这些「记录在磁盘上的寄存形式」也被称为行格局或者记录格局。行格局有4种，别离是Dynamic、Compact、Redundant和Compressed

MySQL 5+默认行格局都是Dynamic， 在MySQL 5 和 MySQL 8通过验证的确是的。

SHOW VARIABLES LIKE "innodb_default_row_format"

大家在业务中和平时应用中都简直没有批改过或者留神过InnoDB行格局，那么「我就只重点讲默认行格局dynamic」，让大家更深层次了解平时开发中的varchar。

请记住这个表构造，前面会围绕这个来讲

CREATE TABLE test (c1 VARCHAR(10),c2 VARCHAR(10) NOT NULL,c3 CHAR(10),c4 VARCHAR(10)) CHARSET = utf8mb4;

当初业务数据库字符集都是utf8mb4，我就以这个来讲，把了解难度降到最低。

INSERT INTO test ( 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」)占用的存储空间分为两局部：

  1. 真正的数据内容局部，放在对应的列
  2. 实在占用的字节数，放在变长字段列表局部

❞

咱们拿test表中的第一条记录来举个例子。因为test表的c1、c2、c4列都是VARCHAR(10)类型的，阐明最大10个字符，所以这三个列的值的长度都须要保留在记录结尾处，「因为test表中的各个列都应用的是utf8mb4字符集，每个字符最大须要4个字节来进行编码（不应用utf8而是utf8mb4是因为可能存储emoji表情，如果只是文字，utf8就足够）」，来看一下第一条记录各变长字段内容的长度：

列名存储内容内容长度（十进制示意）内容长度（十六进制示意）
c1‘aaaa’4 字节0x04
c2‘你好啊’9 字节0x09
c4‘d’1 字节0x01

怎么确定这些字段有多少字节？

比方这里c2的"你好啊"，应用如下sql能够确定

SELECT LENGTH(c2) from test where 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。

我做了个测试

create table t2 ( name varchar(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值。

  1. 「如果表中没有容许存储 NULL 的列，则 NULL值列表也不存在了」，否则将每个容许存储NULL的列对应一个二进制位，二进制位依照列的程序「逆序排列」。二进制位的值为1时，代表该列的值为NULL，为0时，代表该列的值不为NULL。因为表test的c1、c3、c4都是容许存储NULL值的容许为NULL的列，所以这3个列和二进制位的对应关系就是这样：

  1. 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格局了解就能够，更贴近理论开发。

起源：https://blog.csdn.net/qq_3411...

近期热文举荐：

1.1,000+ 道 Java面试题及答案整顿(2022最新版)

2.劲爆！Java 协程要来了。。。

3.Spring Boot 2.x 教程，太全了！

4.别再写满屏的爆爆爆炸类了，试试装璜器模式，这才是优雅的形式！！

5.《Java开发手册（嵩山版）》最新公布，速速下载！

感觉不错，别忘了顺手点赞+转发哦！