JAVA面试八股文之数据库

Myth丶恋晨 2024-04-17 06:46 124阅读 0赞

#### MySQL面试题 ####

*  MySQL 存储引擎架构了解吗？
 *  CHAR 和 VARCHAR 的区别是什么？
 *  索引是越多越好嘛？
 *  MySQL数据库中空值（null）和空字符串（''）的区别？
 *  SQL 中 on 条件与 where 条件的区别？
 *  Explain执行计划？
 *  Explain执行计划结果参数的含义？
 *  数据库的存储引擎？
 *  数据库的3范式？
 *  为什么用B+树不用B树？
 *  用了索引还是很慢，可能是什么原因？
 *  左连接、右连接、内连接的区别？
 *  MySQL中，如何定位慢查询?
 *  那这个SQL语句执行很慢, 如何分析呢？
 *  了解过索引吗？（什么是索引）
 *  索引的底层数据结构了解过嘛 ?
 *  B树和B+树的区别是什么呢？
 *  什么是聚簇索引什么是非聚簇索引（二级索引） ?
 *  知道什么是回表查询嘛 ?
 *  知道什么叫覆盖索引嘛 ?
 *  MYSQL超大分页怎么处理 ?
 *  索引创建原则有哪些？
 *  什么情况下索引会失效 ?
 *  sql的优化的经验
 *  创建表的时候，你们是如何优化的呢？
 *  那在使用索引的时候，是如何优化呢？
 *  你平时对sql语句做了哪些优化呢？
 *  事务的特性是什么？可以详细说一下吗？
 *  并发事务带来哪些问题？
 *  怎么解决这些问题呢？MySQL的默认隔离级别是？
 *  Binlog、undo log和redo log的区别？
 *  事务中的隔离性是如何保证的呢？(你解释一下MVCC)
 *  MySQL主从同步原理 ？
 *  你们项目用过MySQL的分库分表吗？
 *  那你之前使用过水平分库吗？

## MySQL 存储引擎架构了解吗？ ##

MySQL 存储引擎采用的是 **插件式架构** ，支持多种存储引擎，我们甚至可以为不同的数据库表设置不同的存储引擎以适应不同场景的需要。**存储引擎是基于表的，而不是数据库**。

并且，你还可以根据 MySQL 定义的存储引擎实现标准接口来**编写一个属于自己的存储引擎**。这些非官方提供的存储引擎可以称为**第三方存储引擎**，区别于官方存储引擎。像目前最常用的 InnoDB 其实刚开始就是一个第三方存储引擎，后面由于过于优秀，其被 Oracle 直接收购了。

## CHAR 和 VARCHAR 的区别是什么？ ##

CHAR 和 VARCHAR 是最常用到的字符串类型，两者的主要区别在于：**CHAR 是定长字符串，VARCHAR 是变长字符串。**

## 索引是越多越好嘛？ ##

索引并不是越多越好，索引固然可以提⾼相应的 select 的效率，但同时也降低了 insert 及  
update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况⽽定。⼀个表的索引数最好不要超过6个，若太多则应考虑⼀些不常使⽤到的列上建的索引是否有必要。

## MySQL数据库中空值（null）和空字符串（‘’）的区别？ ##

*  空字符串(’’)的长度是0，是不占用空间的；而的NULL的长度是NULL，其实它是占用空间的。
 *  当字段不为NULL时，也可以插入空字符串；
 *  NULL值查询使用is null/is not null查询，而空字符串(’’)可以使用=或者!=、<、>等算术运算符。
 *  使用 COUNT(字段) 统计会过滤掉 NULL 值，但是不会过滤掉空字符串。

## SQL 中 on 条件与 where 条件的区别？ ##

*  1、on 条件是在生成临时表时使用的条件，它不管 on 中的条件是否为真，都会返回左边表中的记录。
 *  2、where 条件是在临时表生成好后，再对临时表进行过滤的条件。这时已经没有 left join 的含义（必须返回左边表的记录）了，条件不为真的就全部过滤掉。

## Explain执行计划？ ##

> Explain是 SQL 分析工具中非常重要的一个功能，它可以模拟优化器执行查询语句，帮助我们理解查询是如何执行的；分析查询执行计划可以帮助我们发现查询瓶颈，优化查询性能。如下：  
> ① 表的读取顺序  
> ② SQL执行时查询操作类型  
> ③可以使用哪些索引  
> ④ 实际使用哪些索引  
> ⑤每张表有多少行记录被扫描  
> ⑥SQL语句性能分析

## Explain执行计划结果参数的含义？ ##

![在这里插入图片描述][b4031728866e4acf9f51ccc94f56e88c.png]

*  **id**：id越大先执行，id相同则由上往下执行;
 *  **select\_type**:查询的类型,主要用于区别普通查询,联合查询,子查询等复杂查询；
 *  **table**:显示一行数据是属于哪张表的；
 *  **type**：查询类型从最好到最差依次是:system>const>eq\_ref>ref>range>index>All,一般情况下,得至少保证达到index级别,最好能达到ref。
 *  **possible\_keys**：显示可能应用在这张表中的索引,一个或多个,查询到的索引不一定是真正被用到的；
 *  **key**：实际使用的索引,如果为null,则没有使用索引,因此会出现possible\_keys列有可能被用到的索引,但是key列为null,表示实际没用索引。；
 *  **key-length**：表示索引中使用的字节数,而通过该列计算查询中使用的 索引长度,在不损失精确性的情况下,长度越短越好,keylen显示的值为索引字段的最大可能长度,并非实际使用长度；
 *  **ref：** 显示索引的哪一列被使用了；
 *  **rows：** 全表扫描时表示需要扫描表的行数估计值；索引扫描时表示扫描索引的行数估计值；值越小越好（不是结果集中的行数）
 *  **Extra**：Extra 列表示 SQL 执行查询的一些额外信息。

## 数据库的存储引擎？ ##

常用的存储引擎有以下：

●  
**Innodb引擎**：Innodb引擎提供了对数据库ACID事务的支持。并且还提供了行级锁和外键的约束。它的设计的目标就是处理大数据容量的数据库系统。MySQL默认值的存储引擎。  
●  
**MyIASM引擎**：不提供事务的支持，也不支持行级锁和外键，查询效率高，储存空间小。

InnoDB：表的数据是存储在磁盘中，真正处理数据的过程发生在内存中，所以需要把磁盘中的数据加载到内存中。如果是处理写入请求，还需要把内存中的内容刷新到磁盘上。

InnoDB 采取的方式是，将数据划分为若干个页，以页作为磁盘和内存之间交互的基本单位。InnoDB 中页的大小一股为16KB。也就是在一般情况下，一次最少从磁盘中读取 16KB 的内容到内存中，一次最少把内存中的 16KB 内容刷新到磁盘中。

**如何查找一条数据：**  
1、先在B+数中找到记录所在的页；  
2、把页加载入内存；  
3、通过 Page Directory 进行二叉查找。因为 Page Directory 是稀疏的所有只能找到大概位置；  
4、在步骤3的基础上继续根据记录偏移量一行一行的查找；

## 数据库的3范式？ ##

*  第一范式：原子性，数据库表中的所有字段值都是不可再分的原子值；
 *  第二范式：唯一性，数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关；
 *  第三范式：独立性，确保数据表中的每一列数据都和主键直接相关，而不能间接相关，消除传递依赖(非主键值不依赖于另一个非主键值)

## 为什么用B+树不用B树？ ##

我认为有四点：

*  **B+树的磁盘读写代价更低**：B+树非叶子节点不存放数据，只存放指针，扫描的数据更多；
 *  **B+树的查询效率更加稳定**：B+树只在叶子节点存放数据，所以查询的路径长度相同；
 *  **B+树更便于遍历**：B+树只需要扫描一遍叶子节点就可以；
 *  **B+树更适合基于范围的查询：** B+树都在叶子节点存储数据且顺序排列，并且叶子节点是一个双向链表；

## 用了索引还是很慢，可能是什么原因？ ##

*  选错索引：当存在多个索引时，mysql的优化器会选择一个，所以可能导致选错。
 *  数据分布不均匀：如果数据分布不匀,就可能导致某些索弓|节点的数据量很大，而另外一些节点的数据量很少，从而使查询性能下降。
 *  sql语句存在问题
 *  数据库设计不合理

## 左连接、右连接、内连接的区别？ ##

左连接是查询左侧表中的所有记录以及右侧表中与之匹配的记录，  
而右连接是查询右侧表中的所有记录以及左侧表中与之匹配的记录  
内连接是查询两张表中有交集的部分；

## MySQL中，如何定位慢查询? ##

我们当时做压测的时候有的接口非常的慢，接口的响应时间超过了2秒以上，因为我们当时的系统部署了运维的监控系统Skywalking ，在展示的报表中可以看到是哪一个接口比较慢，并且可以分析这个接口哪部分比较慢，这里可以看到SQL的具体的执行时间，所以可以定位是哪个sql出了问题。  
如果，项目中没有这种运维的监控系统，其实在MySQL中也提供了慢日志查询的功能，可以在MySQL的系统配置文件中开启这个慢日志的功能，并且也可以设置SQL执行超过多少时间来记录到一个日志文件中，我记得上一个项目配置的是2秒，只要SQL执行的时间超过了2秒就会记录到日志文件中，我们就可以在日志文件找到执行比较慢的SQL了。

## 那这个SQL语句执行很慢, 如何分析呢？ ##

如果一条sql执行很慢的话，我们通常会使用mysql自动的执行计划explain来去查看这条sql的执行情况，比如在这里面可以通过key和key\_len检查是否命中了索引，如果本身已经添加了索引，也可以判断索引是否有失效的情况，第二个，可以通过type字段查看sql是否有进一步的优化空间，是否存在全索引扫描或全盘扫描，第三个可以通过extra建议来判断，是否出现了回表的情况，如果出现了，可以尝试添加索引或修改返回字段来修复

## 了解过索引吗？（什么是索引） ##

索引在项目中还是比较常见的，它是帮助MySQL高效获取数据的数据结构，主要是用来提高数据检索的效率，降低数据库的IO成本，同时通过索引列对数据进行排序，降低数据排序的成本，也能降低了CPU的消耗。

## 索引的底层数据结构了解过嘛 ? ##

MySQL的默认的存储引擎InnoDB采用的B+树的数据结构来存储索引，选择B+树的主要的原因是：第一阶数更多，路径更短，第二个磁盘读写代价B+树更低，非叶子节点只存储指针，叶子阶段存储数据，第三是B+树便于扫库和区间查询，叶子节点是一个双向链表

## B树和B+树的区别是什么呢？ ##

B数：  
![在这里插入图片描述][4784429ea8d646a79b1bab47dae5bdc7.png]  
B+数：  
![在这里插入图片描述][165fddc0794642cdb0622181d84a0d98.png]

第一：在B树中，非叶子节点和叶子节点都会存放数据，而B+树的所有的数据都会出现在叶子节点，在查询的时候，B+树查找效率更加稳定；

第二：在进行范围查询的时候，B+树效率更高，因为B+树都在叶子节点存储，并且叶子节点是一个双向链表；

## 什么是聚簇索引什么是非聚簇索引（二级索引） ? ##

![在这里插入图片描述][e2a4161ffd0e4ea080b40d9648770deb.png]  
举个栗子：  
![在这里插入图片描述][04e69bcc24f04e268a6b2f9a9c391dfe.png]

聚簇索引主要是指数据与索引放到一块，B+树的叶子节点保存了整行数据，有且只有一个，一般情况下主键在作为聚簇索引的。

非聚簇索引值的是数据与索引分开存储，B+树的叶子节点保存对应的主键，可以有多个，一般我们自己定义的索引都是非聚簇索引。  
w

## 知道什么是回表查询嘛 ? ##

这个和聚簇索引和非聚簇索引是有关系的，回表的意思就是通过二级索引找到对应的主键值，然后再通过主键值找到聚集索引中所对应的整行数据，这个过程就是回表。

## 知道什么叫覆盖索引嘛 ? ##

覆盖索引是指select查询语句使用了索引，在返回的列，必须在索引中全部能够找到，如果我们使用id查询，它会直接走聚集索引查询，一次索引扫描，直接返回数据，性能高。

如果按照二级索引查询数据的时候，返回的列中没有创建索引，有可能会触发回表查询，尽量避免使用select \*，尽量在返回的列中都包含添加索引的字段。

## MYSQL超大分页怎么处理 ? ##

超大分页一般都是在数据量比较大时，我们使用了limit分页查询，并且需要对数据进行排序，这个时候效率就很低，我们可以采用覆盖索引和子查询来解决。  
![在这里插入图片描述][46c5fd31fa4145fcaba4419d8a929d2f.png]  
先分页查询数据的id字段，确定了id之后，再用子查询来过滤，只查询这个id列表中的数据就可以了。  
![在这里插入图片描述][ef28f91abff7452082bc92e748ab5bda.png]  
因为查询id的时候，走的覆盖索引，所以效率可以提升很多。

## 索引创建原则有哪些？ ##

这个情况有很多，不过都有一个大前提，就是表中的数据要超过10万以上，我们才会创建索引，并且添加索引的字段是查询比较频繁的字段，一般也是像作为查询条件，排序字段或分组的字段这些。

还有就是，我们通常创建索引的时候都是使用复合索引来创建，一条sql的返回值，尽量使用覆盖索引，如果字段的区分度不高的话，我们也会把它放在组合索引后面的字段。

如果某一个字段的内容较长，我们会考虑使用前缀索引来使用，当然并不是所有的字段都要添加索引，这个索引的数量也要控制，因为添加索引也会导致新增改的速度变慢。

## 什么情况下索引会失效 ? ##

比如，第一个是，索引在使用的时候没有遵循最左匹配法则；  
![在这里插入图片描述][0173b0db4b8442e293975aeb674babdf.png]  
第二个是，如果在添加索引的字段上进行了运算操作或者类型转换也都会导致索引失效。  
第三个是，字符串不加单引号，造成索引失效。  
第四个是，以%开头的like模糊查询，索引失效，如果%在前面索引失效，%在后面索引不失效。  
第五个是，如果使用了复合索引，中间使用了范围查询，右边的条件索引也会失效。  
第六个是，查询条件中有or,即使有部分条件带索引也会失效。

所以，通常情况下，想要判断出这条sql是否有索引失效的情况，可以使用explain执行计划来分析。

## sql的优化的经验 ##

我觉得可以分为几个方面：  
1、使用合适的索引：通过在经常查询的字段上创建索引，可以加快查询速度。  
2、优化查询语句：尽量避免使用SELECT \*，只选择需要的字段；尽量避免在字段开头模糊查询，多表关联以小表为驱动，尽量避免null值的判断，多次插入改为批量插入。  
3、优化数据库结构：合理设计数据库表结构，避免过多的冗余字段和表关联、使用合适的数据类型。  
4、业务方面：对于频繁查询的结果可以进行缓存，减少数据库查询的次数。  
![在这里插入图片描述][9d5ba2e758c34f5985f19395d2193c2d.png]  
建表的时候、使用索引、sql语句的编写、主从复制，读写分离，还有一个是如果量比较大的话，可以考虑分库分表。  
![在这里插入图片描述][b885e3f9a3154fdf923c25216da96568.png]

## 创建表的时候，你们是如何优化的呢？ ##

这个我们主要参考的阿里出的那个开发手册《嵩山版》，就比如，在定义字段的时候需要结合字段的内容来选择合适的类型，如果是数值的话，像tinyint、int 、bigint这些类型，要根据实际情况选择。如果是字符串类型，也是结合存储的内容来选择char和varchar或者text类型

## 那在使用索引的时候，是如何优化呢？ ##

当表中的数据要超过10万以上，创建索引；  
字段是查询比较频繁的字段，一般也是像作为查询条件，排序字段或分组的字段，创建索引；  
通常创建索引的时候都是使用复合索引来创建，一条sql的返回值，尽量使用覆盖索引，如果字段的区分度不高的话，我们也会把它放在组合索引后面的字段。

如果某一个字段的内容较长，我们会考虑使用前缀索引来使用，【当然并不是所有的字段都要添加索引，这个索引的数量也要控制，因为添加索引也会导致新增改的速度变慢。】

## 你平时对sql语句做了哪些优化呢？ ##

1、尽量避免在字段开头模糊查询  
2、SELECT语句务必指明字段名称，不要直接使用select \* ，  
3、还有就是要注意SQL语句避免造成索引失效的写法；如果是聚合查询，尽量用union all代替union ，union会多一次过滤，效率比较低；  
4、如果是表关联的话，尽量使用innerjoin ，不要使用用left join right join，如必须使用 一定要以小表为驱动。  
5、尽量避免进行null值的判断；  
6、尽量避免在where条件中等号的左侧进行表达式；  
7、多次插入改为批量插入

## 事务的特性是什么？可以详细说一下吗？ ##

ACID，分别指的是：原子性、一致性、隔离性、持久性；  
![在这里插入图片描述][8f76a696d1ca4d25bc00f392e1adc105.png]  
我举个例子：  
A向B转账500，转账成功，A扣除500元，B增加500元，原子操作体现在要么都成功，要么都失败；

在转账的过程中，数据要一致，A扣除了500，B必须增加500；

在转账的过程中，隔离性体现在A像B转账，不能受其他事务干扰；

在转账的过程中，持久性体现在事务提交后，要把数据持久化（可以说是落盘操作）；

## 并发事务带来哪些问题？ ##

![在这里插入图片描述][4359c230db3e41f183e27c891505da94.png]  
第一是脏读， 当一个事务正在访问数据并且对数据进行了修改，而这种修改还没有提交到数据库中，这时另外一个事务也访问了这个数据，因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是“脏数据”，依据“脏数据”所做的操作可能是不正确的。

第二是不可重复读：比如在一个事务内多次读同一数据。在这个事务还没有结束时，另一个事务也访问该数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。这就发生了在一个事务内两次读到的数据是不一样的情况，因此称为不可重复读。

第三是幻读（Phantom read）：幻读与不可重复读类似。它发生在一个事务（T1）读取了几行数据，接着另一个并发事务（T2）插入了一些数据时。在随后的查询中，第一个事务（T1）就会发现多了一些原本不存在的记录，就好像发生了幻觉一样，所以称为幻读。

## 怎么解决这些问题呢？MySQL的默认隔离级别是？ ##

解决方案是对事务进行隔离：  
![在这里插入图片描述][e0b2663829674d52b2d4393af294322b.png]  
MySQL支持四种隔离级别，分别有：

第一个是，未提交读（read uncommitted）它解决不了刚才提出的所有问题，一般项目中也不用这个。  
第二个是读已提交（read committed）它能解决脏读的问题的，但是解决不了不可重复读和幻读。  
第三个是可重复读（repeatable read）它能解决脏读和不可重复读，但是解决不了幻读，这个也是mysql默认的隔离级别。  
第四个是串行化（serializable）它可以解决刚才提出来的所有问题，但是由于让是事务串行执行的，性能比较低。所以，我们一般使用的都是mysql默认的隔离级别:可重复读。

## Binlog、undo log和redo log的区别？ ##

![在这里插入图片描述][7e809d8e19684374a5e1d48db175758e.png]  
其中redo log日志记录的是数据页的物理变化，服务宕机可用来同步数据；  
![在这里插入图片描述][a239dce2b1c143078d32d71f11708749.png]  
而undo log 不同，它主要记录的是逻辑日志，当事务回滚时，通过逆操作恢复原来的数据，比如我们删除一条数据的时候，就会在undo log日志文件中新增一条insert语句，如果发生回滚就执行逆操作；

Binlog是MySQL用于记录数据库中的所有DDL语句和DML语句的一种二进制日志。它记录了所有对数据库结构和数据的修改操作，如INSERT、 UPDATE和DELETE等。 binlog主要用来对数据库进行数据备份、灾难恢复和数据复制等操作。binlog的格式分为基于语句的格式和基于行的格式，还可以用来做主从同步。

redo log保证了事务的持久性，undo log保证了事务的原子性和一致性。

## 事务中的隔离性是如何保证的呢？(你解释一下MVCC) ##

事务的隔离性是由锁和mvcc实现的。

其中mvcc的意思是多版本并发控制。指维护一个数据的多个版本，使得读写操作没有冲突，它的底层实现主要是分为了三个部分，第一个是隐藏字段，第二个是undo log日志，第三个是readView读视图；

隐藏字段是指：在mysql中给每个表都设置了隐藏字段，有一个是trx\_id(事务id)，记录每一次操作的事务id，是自增的；另一个字段是roll\_pointer(回滚指针)，指向上一个版本的事务版本记录地址；  
![在这里插入图片描述][8c56dd90653d45789be511006cb9c38f.png]  
undo log主要的作用是记录回滚日志，存储老版本数据，在内部会形成一个版本链，在多个事务并行操作某一行记录，记录不同事务修改数据的版本，通过roll\_pointer指针形成一个链表；  
![在这里插入图片描述][4cfcdd42a5af43dabf884277375d9108.png]  
readView解决的是一个事务查询选择版本的问题，在内部定义了一些匹配规则和当前的一些事务id判断该访问那个版本的数据，不同的隔离级别快照读是不一样的，最终的访问的结果不一样。如果是rc隔离级别，每一次执行快照读时生成ReadView，如果是rr隔离级别仅在事务中第一次执行快照读时生成ReadView，后续复用；

## MySQL主从同步原理 ？ ##

MySQL主从复制的核心就是二进制日志(DDL（数据定义语言）语句和 DML（数据操纵语言）语句)，它的步骤是这样的：

第一：主库在事务提交时，会把数据变更记录在二进制日志文件 Binlog 中。

第二：从库读取主库的二进制日志文件 Binlog ，写入到从库的中继日志 Relay Log 。

第三：从库再执行中继日志中的事件，将改变写入它自己的数据。  
![在这里插入图片描述][4f4cfb4db4564b9887201a9ffccb38ca.png]

## 你们项目用过MySQL的分库分表吗？ ##

因为我们都是微服务开发，每个微服务对应了一个数据库，是根据业务进行拆分的，这个其实就是垂直拆分。  
![在这里插入图片描述][12065f02bc344c42ba9e616929db2116.png]

*  并发高：分库
 *  数据量大：分表

## 那你之前使用过水平分库吗？ ##

这个是使用过的，我们当时的业务是(xxx)，一开始，我们也是单库，后来这个业务逐渐发展，业务量上来的很迅速，其中(xx)表已经存放了超过1000万的数据，我们做了很多优化也不好使，性能依然很慢，所以当时就使用了水平分库。

我们一开始先做了3台服务器对应了3个数据库，由于库多了，需要分片，我们当时采用的mycat来作为数据库的中间件。数据都是按照id（自增）取模的方式来存取的。

当然一开始的时候，那些旧数据，我们做了一些清洗的工作，我们也是按照id取模规则分别存储到了各个数据库中，好处就是可以让各个数据库分摊存储和读取的压力，解决了我们当时性能的问题。

**后记  
????美好的一天，到此结束，下次继续努力！欲知后续，请看下回分解，写作不易，感谢大家的支持！！ ???**

[b4031728866e4acf9f51ccc94f56e88c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/15/103eb1aa81e04fda8ce5e0c5d00c39be.png
[4784429ea8d646a79b1bab47dae5bdc7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/15/5cce6a8800494da68bfb58c1da4996ab.png
[165fddc0794642cdb0622181d84a0d98.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/15/ec8a786bcf234a48887d5de48d72c1fe.png
[e2a4161ffd0e4ea080b40d9648770deb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/15/dc458400deef496e86e14eb51201313c.png
[04e69bcc24f04e268a6b2f9a9c391dfe.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/15/355652f6c50a40959a58fe74c510d677.png
[46c5fd31fa4145fcaba4419d8a929d2f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/15/01fc4cd592074db7852bef88b96d6d29.png
[ef28f91abff7452082bc92e748ab5bda.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/15/61d33bf5c2994716ad7cf49d5e1c595a.png
[0173b0db4b8442e293975aeb674babdf.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/15/e55b604fa90f410b9d3e6ef3d399e8e8.png
[9d5ba2e758c34f5985f19395d2193c2d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/15/dbef0877785748d3bec37dbbe0af53be.png
[b885e3f9a3154fdf923c25216da96568.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/15/59c0eece97864c948f112c52d1b335b7.png
[8f76a696d1ca4d25bc00f392e1adc105.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/15/8763083deb9f4a89805642156d0c7232.png
[4359c230db3e41f183e27c891505da94.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/15/a1b6a4c9a40c4595906c91a1a049c253.png
[e0b2663829674d52b2d4393af294322b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/15/22a3e3c8b52f402889b31fd9419236b8.png
[7e809d8e19684374a5e1d48db175758e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/15/eeba6187b8334e199f164686672f3fd6.png
[a239dce2b1c143078d32d71f11708749.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/15/5da3b066397745fb9a1047aa77e0e6c1.png
[8c56dd90653d45789be511006cb9c38f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/15/a4c46c62587a404498c460f55f0e8795.png
[4cfcdd42a5af43dabf884277375d9108.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/15/70d4587ba77343e7935d2093d674dc43.png
[4f4cfb4db4564b9887201a9ffccb38ca.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/15/a3f63538ec144d2d925f057d57c433ec.png
[12065f02bc344c42ba9e616929db2116.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/15/5a3301699f0a41f69c4cf0305018875d.png