关于java:面试官MySQL-中的-varchar-最多能存储多少个字符大部分人都会答错

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就足够）」，来看一下第一条记录各变长字段内容的长度：

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

比方这里 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 开发手册（嵩山版）》最新公布，速速下载！

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