MySQL 的 varchar 存储原理：InnoDB 记录存储结构

た入场券 2024-03-22 17:39 114阅读 0赞

### **1.** InnoDB 是干嘛的？ ###

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

### 2. InnoDB 是如何读写数据的？ ###

InnoDB 处理数据的过程是发生在内存中的，需要把磁盘中的数据加载到内存中，如果是处理写入或修改请求的话，还需要把内存中的内容刷新到磁盘上。

读写磁盘的速度非常慢，和内存读写差了几个数量级，所以当我们想从表中获取某些记录时，InnoDB 存储引擎将数据划分为若干个页，以**页作为磁盘和内存之间交互的基本单位**，InnoDB 中页的大小默认为 16 KB。也就是在一般情况下，一次最少从磁盘中读取 16KB 的内容到内存中，或者一次最少把内存中的 16KB 内容刷新到磁盘中。

所以当你用 postman 测试一个 HTTP 分页查询接口（每页 10 条数据）时，发现第一次打印耗时 300 ~ 400ms，往后不停的查找下一页 10 条数据时都是 30 ~ 40ms，原因就是第一次请求接口时，读数据库的时候需要读磁盘，从磁盘加载 16KB 的数据到内存，往后 HTTP 请求每次查 10 条数据的时候都是从内存中获取，没有再读磁盘，除非在内存中的 16KB 的数据中找不到，才会再次读磁盘获取下一个 16KB 的数据到内存中。（我们不讨论 mysql 8.0 舍弃的查询缓存特性，我测试过 mysql 5.7 中关闭了查询缓存，也仍然是第一次慢，后续查询很快，查询时间相差大概 10 倍的样子）

温馨提示：分页查询和数据库的一页 16KB 中的 "页" 是两个概念。

总结：由于磁盘 I/O 速度相对内存来说较慢，因此第一次查询可能会比较耗时。一旦数据被加载到内存中，后续的查询就可以直接从内存中读取数据，这样的速度要比从磁盘读取数据快得多。这就解释了为什么第一次查询可能会比后续的查询慢。

查看磁盘和内存之间进行数据交换的页有多大

![f409cebf79fdf3d089fb6a630ad15e83.png][]

注意：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"

![4675e8714450bd3fd71ad8056b1dc873.png][]

大家在业务中和平时使用中都几乎没有修改过或者注意过 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);

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

![e5ad07f76246a6b992a300c5453458bc.png][]

#### 3.1 dynamic——innodb 默认行格式 ####

![5f553913ae499d40658ee2449fad7b1d.png][]

关于记录的额外信息这部分，是服务器为了描述这条记录而不得不额外添加的一些信息，这些额外信息分为 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 就足够）**，来看一下第一条记录各变长字段内容的长度：

![25c3a3dfea23668ddd38ae00ec0a0b64.png][]

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

比如这里 c2 的 "你好啊"，使用如下 sql 可以确定

SELECT LENGTH(c2) from test where c1='aaaa';

![942212da781561615601d9ade4b2d209.png][]

![2ade088e3f771c55ba3ea6ef7315ca97.png][]

各变长字段数据占用的**字节数**按照列的顺序**逆序存放**！！

由于第一行记录中 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 个字符放不下吗？

![f20079ef86358ac39b85f21ebd6c57fa.png][]

为什么提示只能最大 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。

2. 对于变长类型 VARCHAR (M) 来说，这种类型表示能存储最多 M 个字符（注意是字符不是字节）  
所以这个类型能表示的字符串最多占用的字节数就是 M × W。

3. 假设它实际存储的字符串占用的字节数是 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;

![b605d5ebeff106547b1de49bb4b6e4ba.png][]

不断往这个字段添加字符保存测试，最后发现，这些字符总长度到极限也就是 48545 字节。

![9d1b7dd87db69416eed384e936a062c3.png][]

如果超过就会报错

![13586466523f1b57d008dd6968314310.png][]

这里 48545 个字节，再多一个字符就会报错，远不到 65535 字节，差了 1W 多字节。主要是因为溢出列的原因，数据分散在不同的行中，所以，很长的数据，建议往 text 类型考虑。这个现象可以看出，varchar (M) 的 M 很大，实际是达不到 M 这个边界值的。

我使用的是英文字母测试而不是中文字符，大部分不是 4 字节的，所以能够存储更多的字符。如果考虑到额外的元数据，实际能够存储的 VARCHAR 字符数会更少，**关于影响每行的实际可用空间有哪些因素，请接着往下看后面小节**。

下面说明一下规则 (讲解中字符集用 utf8mb4，W=4)

**规则一：如果允许存储的最大字节数 M × W <= 255，varchar 占用的真实字节数 L 只分配 1 个字节来表示。**

有人说，允许存储的最大字节数 M × W <= 255，即允许存储的最大字符数 <= ⌊255 / 4⌋ = **63** 个时，varchar 占用的真实字节数 L 仅分配 1 个字节就能表示。这个结论正确吗？

显然错误，因为这里 255 / **4**，你怎么知道每个存储的一个字符是 4 个字节呢？难道全部存的 emoji 表情？不存字母汉字啥的？

实际上不是所有的字符都会占用 W 个字节。例如，在 utf8mb4 字符集中，一个英文字母只占用 1 个字节，而一个 emoji 表情符号会占用 4 个字节。因此，“最多 M 个字符” 并不意味着总是需要 M × W 个字节。  
InnoDB 在读记录的变长字段长度列表时先查看表结构，如果某个变长字段允许存储的最大字节数不大于 255 时，只用 1 个字节来表示真实数据占用的字节。

**规则二：如果允许存储的最大字节数 M × W > 255，则分为两种情况：**

如果实际存储字节 L <= 127，varchar 占用的真实字节数 L 仅分配 1 个字节就能表示。(⌊ … ⌋表示向下取整)

有人说，实际存储字节 L <= 127，即**实际存储字符** <= ⌊127 / 4⌋ = **31** 个时，varchar 占用的真实字节数 L 仅分配 1 个字节就能表示。这个结论正确吗？

还是错误，道理和上面一样。

如果实际存储字节 L > 127，varchar 占用的真实字节数 L 需要分配 2 个字节才能表示。

另外需要注意的是，变长字段列表只存储非 NULL 的列的长度。

表记录是这样的

![7ec1fbdf10254e1f3620121588d76f53.png][]

对于第二条记录，c4 列值为 NULL，所以只存储 c1 和 c2 列即可。

![965d6a24983ecf3c08903686ac0aaa06.png][]

第一条记录的变长字段长度列表部分占用 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 个列和二进制位的对应关系就是这样：

![2514c2671af69392f595e9b3b4dcaba1.png][]

3.NULL 值列表必须用整数个字节的位表示，如果使用的二进制位个数不是整数个字节，则在字节的**高位补 0**。

也就是说，表 test 只有 3 个字段允许为 NULL，对应 3 个二进制位，不足 1 字节，那么就在高位补 0 即可。

![3d0122dcf0c8c4fd021a3fef9876f5eb.png][]

以此类推，如果表中有 9 个字段都允许为 NULL，那么这个记录的 NULL 值列表就需要 2 个字节来表示，高字节高位补 0。

对于**第一条记录**，c1、c3、c4 都不为 NULL，对应的为进制位为 0，十六进制表示就是 0x00

![8794d017669b433c0b6e75f7069b8a97.png][]

对于**第二条记录**，c3、c4 都是 NULL，对应的二进制位为 1，十六进制表示就是 0x06

![d5635e9160eb933eaa75d6413465a714.png][]

这两条记录在填充了 NULL 值列表后示意图如下：

![a43df9e4379236f7fb7121395dcaee80.png][]

#### 3.5 为什么 varchar (16383) 存不到理论字符 16383，影响每行实际可用空间的因素有哪些？ ####

在 utf8mb4 字符集下，VARCHAR (16383) 代表的是最多可以存储 16383 个字符。由于 utf8mb4 编码下，一个字符最多占用 4 个字节，所以理论上 VARCHAR (16383) 最多可以占用 16383 \* 4 = 65532 字节。但是还需要考虑到 InnoDB 的**元数据**和**内部碎片**等空间，由于这些额外的开销，无法在一个 VARCHAR (16383) 字段中存储 16383 个字符。

**内部碎片**：内部碎片主要是由于数据库页（Page）或块（Block）的固定大小导致的。InnoDB 的页大小通常设置为 16KB，每一页中包含了多行数据以及额外的页级元数据。如果一页中的数据没有完全填满这个空间，那么剩余的空间就会成为内部碎片，不能被其他行使用。

内部碎片通常在以下情况中出现：

1.  **固定大小的数据页 / 块**：数据库通常使用固定大小的数据页（例如，在 InnoDB 中，页的大小通常为 16KB）来存储数据。如果一页中的数据没有完全填满这个空间，剩下的空间就会成为内部碎片。
2.  **数据更新**：当一个字段的值被更新为一个更小的值时，剩下的空间可能会成为内部碎片。数据库可能会保留这个空间，以便在未来这个字段的值再次增大时使用。
3.  **预留空间**：为了提高性能，数据库可能会预留一些空间，使得数据的插入和更新操作不需要立即重新分配空间。这些预留的空间也会成为内部碎片。

举个例子：

我们创建一个包含 VARCHAR 字段的表：

CREATE TABLE test (
        id INT AUTO_INCREMENT PRIMARY KEY,
     data VARCHAR(100)
    );

然后我们插入一行数据，其中 data 字段填充了 100 个字符：

INSERT INTO test (data) VALUES (REPEAT('a', 100));

接下来我们更新这行数据，将 data 字段的值改为只有 10 个字符：

UPDATE test SET data = REPEAT('a', 10) WHERE id = 1;

在这个例子中，当我们更新 data 字段的值时，原来占用的 100 个字符的空间并不会立即被收缩，即使新的值只有 10 个字符。这就产生了内部碎片，即那些不再使用但还未被回收的空间。

这种内部碎片化的影响在实际操作中可能并不那么明显，因为数据库系统会尽可能地重用这些空间。如果后续有新的数据需要更多的空间，这些内部碎片的空间就可能会被利用起来。但是如果后续数据主要进行读操作而很少进行写操作的情况下，内部碎片可能会成为影响数据库性能的一个因素。

假设我们有一个包含大量数据的表，这个表目前主要进行读操作，而写操作则相对较少。如果这个表存在大量的内部碎片化（可能是由过去的写操作留下的，例如更新和删除），那么实际存储的数据可能只占用了可用空间的一小部分，大量的空间被内部碎片占用。这种情况下，数据库需要加载更多的页到内存中来获取相同量的数据，这会增加 I/O 操作，从而降低读操作的性能。

除了内部碎片之外，影响每行实际可用空间的其他因素可能包括以下几个：

1.  **元数据**：前文已经介绍，每行的元数据（包括记录头信息、NULL 值列表和变长字段长度列表）都会占用一部分空间。
2.  **行格式**：InnoDB 的行格式（COMPACT，DYNAMIC 或 REDUNDANT）会影响每行的实际可用空间。例如，COMPACT 格式会更紧凑，因此可能会提供更多的可用空间。
3.  **溢出页**：对于非常大的字段（如 BLOB 和 TEXT 类型），InnoDB 可能会将数据存储在单独的溢出页中，而不是直接在数据行中。这可以使得数据行保持较小的大小，但也会增加存储和检索这些字段的复杂性。

以下是一些主要的元数据：

*  **记录头信息**：每一行记录在 InnoDB 中都有一个记录头，包含了一些元数据，如记录类型、下一个记录的位置等。记录头的大小通常为 5-7 字节。
 *  **NULL 值列表**：如果表中的字段允许 NULL 值，InnoDB 会为每一行记录维护一个 NULL 值列表，用于标记哪些字段的值为 NULL。每一个可以为 NULL 的字段会在这个列表中占用 1 位（不是 1 字节）。所以，如果有 n 个字段可以为 NULL，那么 NULL 值列表就需要 n 位，即⌈n/8⌉字节（向上取整）。
 *  **变长字段长度列表**：对于变长字段（如 VARCHAR、VARBINARY、TEXT 和 BLOB 类型），InnoDB 需要存储每个字段实际值的长度。如果字段的最大可能长度不超过 255 字节，那么这个长度值会占用 1 个字节；如果字段的最大可能长度超过 255 字节，那么长度值可能会占用 1 个字节（如果实际长度不超过 127 字节）或 2 个字节（如果实际长度超过 127 字节）。

通常来说，内部碎片和元数据可能会对每行的实际可用空间产生最大的影响。

注意：CHAR 类型和 VARCHAR 类型在元数据和内部碎片方面有些不同：

1.  元数据：由于 CHAR 类型是固定长度的，所以它不需要像 VARCHAR 类型那样存储额外的元数据来表示实际的长度。这意味着对于同样长度的字符串，CHAR 类型会使用更少的空间来存储元数据。
2.  内部碎片：CHAR 类型由于是固定长度的，可能会产生内部碎片。比如，如果定义了一个 CHAR (100) 字段，但实际上只存储了 10 个字符的字符串，那么剩下的 90 个字符的空间就会被浪费，这就是内部碎片。另一方面，VARCHAR 类型只会使用实际所需的空间，因此内部碎片会较少。

所以，尽管 CHAR 类型不需要存储长度的元数据，但它可能会因为固定长度的特性而产生更多的内部碎片。

在 MySQL 中，任何类型的列都可以被声明为 NULL 或 NOT NULL，所以 CHAR 类型也可以有 NULL 值列表。

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

在 MySQL 5.7 及之后的版本中，默认的行格式是 DYNAMIC。在 DYNAMIC 行格式中，如果一个字段的大小超过了页面的可用空间，该字段就会被存储为溢出列。

这里是一个例子：

CREATE TABLE `big_data` (
     `id` int(11) NOT NULL AUTO_INCREMENT,
     `data` longblob,
     PRIMARY KEY (`id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC;

在这个表中，data 列的类型是 longblob，这意味着它可以存储的数据长度最大达到 4GB。如果你插入一个大于 16KB 的数据到这个表，那么 data 列的数据就会被作为溢出列处理。

INSERT INTO big_data (data) VALUES (REPEAT('a', 17000));

在这个例子中，插入的数据长度超过了 16KB，所以 data 列的数据会被作为溢出列处理。在原始的表中，data 列只会存储一个 20 字节的指针，这个指针指向实际数据的存储位置。

这样的设计可以确保每个页内的数据都保持在合理的大小范围内，避免了由于单个字段数据过大导致的页分裂等问题，从而提高了整体的存储效率和查询性能。同时，对于读取溢出列的数据，虽然可能需要额外的磁盘 I/O，但只要数据的访问是顺序的，通常这个开销并不会太大。

[f409cebf79fdf3d089fb6a630ad15e83.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/e5553283b2ce45ffa15eaf781110a37f.png
[4675e8714450bd3fd71ad8056b1dc873.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/4d00a94e46d44ccda6e18ef058207171.png
[e5ad07f76246a6b992a300c5453458bc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/298a0d83189a4cd3ac0d90a65adb0327.png
[5f553913ae499d40658ee2449fad7b1d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/347148fd485d4253993ae00bfd7ad48b.png
[25c3a3dfea23668ddd38ae00ec0a0b64.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/095801ad1e1e41a4be7a4127e264c1c2.png
[942212da781561615601d9ade4b2d209.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/1d8b0aa8613c49ec929fe4047090f8a0.png
[2ade088e3f771c55ba3ea6ef7315ca97.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/a36513622fdd4cdeb8f7f8ee4ca0b20e.png
[f20079ef86358ac39b85f21ebd6c57fa.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/3e6d176774e24ce4bf6914e42b82ff07.png
[b605d5ebeff106547b1de49bb4b6e4ba.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/0f9469790a0a45a69bfbe06d07dbbfde.png
[9d1b7dd87db69416eed384e936a062c3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/0d197580e56c4ac5a7eb42fea6c505e3.png
[13586466523f1b57d008dd6968314310.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/2b49951db8e04b5280693ea5a22ae7db.png
[7ec1fbdf10254e1f3620121588d76f53.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/d1a5152b38db42a79c28e68b2aaff0b0.png
[965d6a24983ecf3c08903686ac0aaa06.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/a88d4762c51242b3a566c4c930c60a2a.png
[2514c2671af69392f595e9b3b4dcaba1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/1077ba24aafe41beb22858e29544dc36.png
[3d0122dcf0c8c4fd021a3fef9876f5eb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/5aaa07bb3e3548c9868874578f573ea7.png
[8794d017669b433c0b6e75f7069b8a97.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/0dc5edcbfa7d4b15a14447f3bfd85887.png
[d5635e9160eb933eaa75d6413465a714.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/7a810711c57441bdb5c7a746f38c2dd2.png
[a43df9e4379236f7fb7121395dcaee80.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/9d00e705fac6466c868f0e7c75e71344.png