MySQL性能瓶颈定位慢查询

╰半夏微凉° 2024-03-17 16:53 37阅读 0赞

#### 目录 ####

*  1 性能优化的思路
 *  2 引言
 *  3 MySQL慢查询日志
 *   *  3.1 慢查询参数
     *  3.2 开启慢查询日志（临时）
     *  3.3 开启慢查询日志（永久）
     *  3.4 慢查询测试
 *  4 MySQL性能分析 EXPLAIN
 *   *  4.1 概述
     *  4.2 EXPLAIN字段介绍
     *   *  4.2.1 id字段
         *  4.2.2 select\_type 与 table字段
         *  4.2.3 type字段
         *  4.2.4 possible\_keys 与 key字段
         *  4.2.5 key\_len字段
         *  4.2.6 ref 字段
         *  4.2.7 rows 字段
         *  4.2.8 filtered 字段
         *  4.2.9 extra 字段

--------------------

## 1 性能优化的思路 ##

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

*  1.  首先需要使用慢查询功能，去获取所有查询时间比较长的SQL语句
 *  1.  其次使用explain命令去查询由问题的SQL的执行计划
 *  1.  最后可以使用show profile\[s\] 查看由问题的SQL的性能使用情况
 *  1.  优化SQL语句

## 2 引言 ##

数据库查询快慢是影响项目性能的一大因素，对于数据库，我们除了要优化SQL，更重要的是得**先找到需要优化的SQL语句**。

MySQL数据库有一个“**慢查询日志**”功能，用来**记录**查询时间**超过某个设定值的SQL**，这将极大程度帮助我们**快速定位到问题所在，以便对症下药**。

## 3 MySQL慢查询日志 ##

慢查询日志用来记录在 MySQL 中执行时间超过指定时间的查询语句。通过慢查询日志，可以查找出哪些查询语句的执行效率低，以便进行优化。

### 3.1 慢查询参数 ###

1.  执行下面的语句

xxxxxxxxxx
    SHOW VARIABLES LIKE "%slow_query%" ;

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

*  **slow\_query\_log**：是否开启慢查询,on为开启,off为关闭;
 *  **log-slow-queries**：慢查询日志文件路径

xxxxxxxxxx
    SHOW VARIABLES LIKE "%long_query_time%" ;

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

*  **long\_query\_time :** 阈值，超过多少秒的查询就写入日志

xxxxxxxxxx
    show variables like 'log_queries_not_using_indexes';

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

*  **系统变量 `log-queries-not-using-indexes`**：未使用索引的查询也被记录到慢查询日志中（可选项）。如果调优的话，建议开启这个选项。

### 3.2 开启慢查询日志（临时） ###

在MySQL执行SQL语句设置,但是如果重启MySQL的话会失效。

xxxxxxxxxx
    set global slow_query_log=on;
    set global long_query_time=1;

### 3.3 开启慢查询日志（永久） ###

修改：/etc/my.cnf，添加以下内容，**然后重启MySQL服务**

xxxxxxxxxx
    [mysqld]
    lower_case_table_names=1
    slow_query_log=ON
    slow_query_log_file=D:\dev\mysql-8.0.22-winx64\data\DESKTOP-LEC7QQM-slow.log
    long_query_time=1

（数据库操作超过100毫秒认为是慢查询，可根据需要进行设定，如果过多，可逐步设定，比如先行设定为2秒，逐渐降低来确认瓶颈所在）

### 3.4 慢查询测试 ###

xxxxxxxxxx
    select SLEEP(3);

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

格式说明：

*  第一行，SQL查询执行的具体时间
 *  第二行，执行SQL查询的连接信息，用户和连接IP
 *  第三行，记录了一些我们比较有用的信息，
    
     *  **Query\_timme，这条SQL执行的时间，越长则越慢**
     *  **Lock\_time，在MySQL服务器阶段(不是在存储引擎阶段)等待表锁时间**
     *  **Rows\_sent，查询返回的行数**
     *  **Rows\_examined，查询检查的行数，越长就越浪费时间**
 *  第四行，设置时间戳，没有实际意义，只是和第一行对应执行时间。
 *  第五行，执行的SQL语句记录信息

## 4 MySQL性能分析 EXPLAIN ##

### 4.1 概述 ###

explain（执行计划），使用explain关键字可以模拟优化器执行sql查询语句，从而知道MySQL是如何处理sql语句。

explain主要用于分析查询语句或表结构的性能瓶颈。

通过explain命令可以得到:

*  – 表的读取顺序
 *  – 数据读取操作的操作类型
 *  – 哪些索引可以使用
 *  – 哪些索引被实际使用
 *  – 表之间的引用
 *  – 每张表有多少行被优化器查询

### 4.2 EXPLAIN字段介绍 ###

explain使用：explain+sql语句，通过执行explain可以获得sql语句执行的相关信息。

xxxxxxxxxx
    explain select * from course;

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

expain出来的信息有10列，分别是id、select\_type、table、type、possible\_keys、key、key\_len、ref、rows、Extra

**数据准备**

xxxxxxxxxx
    -- 创建数据库
    CREATE DATABASE test_explain CHARACTER SET 'utf8';
    
    -- 创建表
    CREATE TABLE L1(id INT PRIMARY KEY AUTO_INCREMENT,title VARCHAR(100) );
    CREATE TABLE L2(id INT PRIMARY KEY AUTO_INCREMENT,title VARCHAR(100) );
    CREATE TABLE L3(id INT PRIMARY KEY AUTO_INCREMENT,title VARCHAR(100) );
    CREATE TABLE L4(id INT PRIMARY KEY AUTO_INCREMENT,title VARCHAR(100) );
    
    -- 每张表插入3条数据
    INSERT INTO L1(title) VALUES('heima001'),('heima002'),('heima003');
    INSERT INTO L2(title) VALUES('heima004'),('heima005'),('heima006');
    INSERT INTO L3(title) VALUES('heima007'),('heima008'),('heima009');
    INSERT INTO L4(title) VALUES('heima010'),('heima011'),('heima012');

#### 4.2.1 id字段 ####

**select查询的序列号，包含一组数字，表示查询中执行select子句或操作表的顺序**

*  id相同，执行顺序由上至下

xxxxxxxxxx
    EXPLAIN SELECT * FROM  L1,L2,L3 WHERE L1.id=L2.id AND L2.id = L3.id;

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

*  id不同，如果是子查询，id的序号会递增，**id值越大优先级越高，越先被执行**

xxxxxxxxxx
    EXPLAIN SELECT * FROM L2 WHERE id = (
      SELECT id FROM L1 WHERE id = (SELECT L3.id FROM L3 WHERE L3.title = 'heima03'));

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

#### 4.2.2 select\_type 与 table字段 ####

**查询类型，主要用于区别普通查询，联合查询，子查询等的复杂查询**

*  `simple` : 简单的select查询，查询中不包含子查询或者UNION

xxxxxxxxxx
    EXPLAIN SELECT * FROM L1;

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

*  `primary` : 查询中若包含任何复杂的子部分，最外层查询被标记
    
        xxxxxxxxxx
    
        EXPLAIN SELECT * FROM L2 WHERE id = (
    
        SELECT id FROM L1 WHERE id = (SELECT L3.id FROM L3 WHERE L3.title = 'heima03'));

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

*  `subquery` : 在select或where列表中包含了子查询
    
        xxxxxxxxxx
    
        EXPLAIN SELECT * FROM L2 WHERE L2.id = (SELECT id FROM L3 WHERE L3.title = 'heima03' )

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

*  `derived` : 在from列表中包含的子查询被标记为derived（衍生），MySQL会递归执行这些子查询， 把结果放到临时表中
 *  `union` : 如果第二个select出现在UNION之后，则被标记为UNION，如果union包含在from子句的子查询中，外层select被标记为derived
 *  `union result` : UNION 的结果
    
        xxxxxxxxxx
    
        EXPLAIN SELECT * FROM L2
    
        UNION
    
        SELECT * FROM L3

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

#### 4.2.3 type字段 ####

**type显示的是连接类型，是较为重要的一个指标。下面给出各种连接类型,按照从最佳类型到最坏类型进行排序:**

xxxxxxxxxx
    system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
    
    -- 简化
    system > const > eq_ref > ref > range > index > ALL

*  **system** : 表仅有一行 (等于系统表)。这是const连接类型的一个特例,很少出现。
 *  **const** : 表示通过索引 一次就找到了, const用于比较 primary key 或者 unique 索引. 因为只匹配一行数据,所以如果将主键 放在 where条件中, MySQL就能将该查询转换为一个常量
    
        xxxxxxxxxx
    
        EXPLAIN SELECT * FROM L1 WHERE L1.id = 1

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

*  **eq\_ref** : 唯一性索引扫描,对于每个索引键,表中只有一条记录与之匹配. 常见与主键或唯一索引扫描
    
        xxxxxxxxxx
    
        EXPLAIN SELECT * FROM L1 ,L2 WHERE L1.id = L2.id ;

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

*  **ref** : 非唯一性索引扫描, 返回匹配某个单独值的所有行, 本质上也是一种索引访问, 它返回所有匹配某个单独值的行, 这是比较常见连接类型.
    
    **未加索引之前**
    
        xxxxxxxxxx
    
        EXPLAIN SELECT * FROM L1 ,L2 WHERE L1.title = L2.title ;

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

**加索引之后**

xxxxxxxxxx

CREATE INDEX idx_title ON L2(title);

EXPLAIN SELECT * FROM L1 ,L2 WHERE L1.title = L2.title ;

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

*  **range** : 只检索给定范围的行,使用一个索引来选择行。
    
        xxxxxxxxxx
    
        EXPLAIN SELECT * FROM L1 WHERE L1.id > 10;
    
        EXPLAIN SELECT * FROM L1 WHERE L1.id IN (1,2);

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

key显示使用了哪个索引. where 子句后面 使用 between 、< 、> 、in 等查询, 这种范围查询要比全表扫描好

*  **index** : 出现index 是 SQL 使用了索引, 但是没有通过索引进行过滤,一般是使用了索引进行排序分组
    
        xxxxxxxxxx
    
        EXPLAIN SELECT * FROM L1 ORDER BY id;

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

*  **ALL** : 对于每个来自于先前的表的行组合,进行完整的表扫描。
    
        xxxxxxxxxx
    
        EXPLAIN SELECT * FROM L1;

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

> **一般来说,需要保证查询至少达到 range级别,最好能到ref**

#### 4.2.4 possible\_keys 与 key字段 ####

*  possible\_keys
    
     *  显示可能应用到这张表上的索引, 一个或者多个. 查询涉及到的字段上若存在索引, 则该索引将被列出, **但不一定被查询实际使用.**
 *  key
    
     *  实际使用的索引，若为null，则没有使用到索引。（两种可能，1.没建立索引, 2.建立索引，但索引失效）。查询中若使用了覆盖索引，则该索引仅出现在key列表中。
     *  覆盖索引：一个索引包含(或覆盖)所有需要查询的字段的值,通过查询索引就可以获取到字段值

1.  理论上没有使用索引,但实际上使用了

xxxxxxxxxx
    EXPLAIN SELECT L1.id FROM L1;

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

1.  理论和实际上都没有使用索引

xxxxxxxxxx
    EXPLAIN SELECT * FROM L1 WHERE title = 'heima01';

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

1.  理论和实际上都使用了索引

xxxxxxxxxx
    EXPLAIN SELECT * FROM L2 WHERE title = 'heima02';

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

#### 4.2.5 key\_len字段 ####

表示索引中使用的字节数, 可以通过该列计算查询中使用索引的长度.

key\_len 字段能够帮你检查是否充分利用了索引 **ken\_len 越长, 说明索引使用的越充分**

*  创建表
    
        xxxxxxxxxx
    
        CREATE TABLE L5(
    
        a INT PRIMARY KEY,
    
        b INT NOT NULL,
    
        c INT DEFAULT NULL,
    
        d CHAR(10) NOT NULL
    
        );
 *  使用explain 进行测试
    
        xxxxxxxxxx
    
        EXPLAIN SELECT * FROM L5 WHERE a > 1 AND b = 1;
    
    **索引中只包含了1列,所以,key\_len是4。**

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

*  为b字段添加索引
    
        xxxxxxxxxx
    
        ALTER TABLE L5 ADD INDEX idx_b(b);
    
        -- 执行SQL,这次将b字段也作为条件
    
        EXPLAIN SELECT * FROM L5 WHERE a > 1 AND b = 1;
    
    再次测试
 *  为c、d字段添加联合索引,然后进行测试
    
        xxxxxxxxxx
    
        ALTER TABLE L5 ADD INDEX idx_c_b(c,d);
    
        explain select * from L5 where c = 1 and d = '';

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

**c字段是int类型 4个字节, d字段是 char(10)代表的是10个字符相当30个字节**

> 数据库的字符集是utf8 一个字符3个字节,d字段是 char(10)代表的是10个字符相当30个字节,多出的一个字节用来表示是联合索引

下面这个例子中,虽然使用了联合索引,但是可以根据ken\_len的长度推测出该联合索引只使用了一部分,没有充分利用索引,还有优化空间.

xxxxxxxxxx
    explain select * from L5 where c = 1 ;

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

#### 4.2.6 ref 字段 ####

*  显示索引的哪一列被使用了，如果可能的话，是一个常数。哪些列或常量被用于查找索引列上的值
    
     *  **L1.id=‘1’; 1是常量 , ref = const**
    
        xxxxxxxxxx
    
        EXPLAIN SELECT * FROM L1 WHERE  L1.id='1';

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

*  **L2表被关联查询的时候,使用了主键索引, 而值使用的是驱动表(执行计划中靠前的表是驱动表)L1表的ID, 所以 ref = test\_explain.L1.id**

xxxxxxxxxx

EXPLAIN SELECT * FROM L1 LEFT JOIN L2 ON  L1.id = L2.id WHERE L1.title = 'heima01';

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

#### 4.2.7 rows 字段 ####

*  **表示MySQL根据表统计信息及索引选用情况，估算的找到所需的记录所需要读取的行数；越少越好**

1.  使用like 查询,会产生全表扫描, L2中有3条记录,就需要读取3条记录进行查找

xxxxxxxxxx
    EXPLAIN SELECT * FROM L1,L2 WHERE L1.id = L2.id AND L2.title LIKE '%hei%';

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

1.  如果使用等值查询, 则可以直接找到要查询的记录,返回即可,所以只需要读取一条

xxxxxxxxxx
    EXPLAIN SELECT * FROM L1,L2 WHERE L1.id = L2.id AND L2.title = 'heima03';

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

**总结: 当我们需要优化一个SQL语句的时候，我们需要知道该SQL的执行计划，比如是全表扫描，还是索引扫描； 使用`explain`关键字可以模拟优化器执行`sql`语句，从而知道`mysql`是如何处理`sql`语句的,方便我们开发人员有针对性的对SQL进行优化.**

*  表的读取顺序。（对应id）
 *  数据读取操作的操作类型。（对应select\_type）
 *  哪些索引可以使用。（对应possible\_keys）
 *  哪些索引被实际使用。（对应key）
 *  每张表有多少行被优化器查询。（对应rows）
 *  评估sql的质量与效率 (对应type)

#### 4.2.8 filtered 字段 ####

*  它指返回结果的行占需要读到的行(rows列的值)的百分比

#### 4.2.9 extra 字段 ####

Extra 是 EXPLAIN 输出中另外一个很重要的列，该列显示MySQL在查询过程中的一些详细信息

*  准备数据
    
        xxxxxxxxxx
    
        CREATE TABLE users (
    
        uid INT PRIMARY KEY AUTO_INCREMENT,
    
        uname VARCHAR(20),
    
        age INT(11)
    
        );
    
        INSERT INTO users VALUES(NULL, 'lisa',10);
    
        INSERT INTO users VALUES(NULL, 'lisa',10);
    
        INSERT INTO users VALUES(NULL, 'rose',11);
    
        INSERT INTO users VALUES(NULL, 'jack', 12);
    
        INSERT INTO users VALUES(NULL, 'sam', 13);
 *  **Using filesort**
    
        xxxxxxxxxx
    
        EXPLAIN SELECT * FROM users ORDER BY age;

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

执行结果Extra为`Using filesort`，这说明，得到所需结果集，需要对所有记录进行文件排序。这类SQL语句性能极差，需要进行优化。

典型的，在一个没有建立索引的列上进行了order by，就会触发filesort，常见的优化方案是，在order by的列上添加索引，避免每次查询都全量排序。

**filtered** 它指返回结果的行占需要读到的行(rows列的值)的百分比

*  **Using temporary**
    
        xxxxxxxxxx
    
        EXPLAIN SELECT COUNT(*),uname FROM users WHERE uid > 2  GROUP BY uname;

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

执行结果Extra为`Using temporary`，这说明需要建立临时表 (temporary table) 来暂存中间结果。 常见与 **group by** 和 **order by**，这类SQL语句性能较低，往往也需要进行优化。

*  **Using where**
    
    意味着全表扫描或者在查找使用索引的情况下,但是还有查询条件不在索引字段当中.
    
        xxxxxxxxxx
    
        EXPLAIN SELECT * FROM users WHERE age=10;

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

此语句的执行结果Extra为Using where，表示使用了where条件过滤数据

**需要注意的是：**

1.  返回所有记录的SQL，不使用where条件过滤数据，大概率不符合预期，对于这类SQL往往需要进行优化；
2.  使用了where条件的SQL，并不代表不需要优化，往往需要配合explain结果中的type（连接类型）来综合判断。例如本例查询的 age 未设置索引，所以返回的type为ALL，仍有优化空间，可以建立索引优化查询。

*  **Using index**
    
    表示直接访问索引就能够获取到所需要的数据(覆盖索引) , 不需要通过索引回表.
    
        xxxxxxxxxx
    
        -- 为uname创建索引
    
        alter table users add index idx_uname(uname);
    
        EXPLAIN SELECT uid,uname FROM users WHERE uname='lisa';

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

此句执行结果为Extra为Using index，说明sql所需要返回的所有列数据均在一棵索引树上，而无需访问实际的行记录。

*  **Using join buffer**
    
    使用了连接缓存, 会显示join连接查询时,MySQL选择的查询算法 .
    
        xxxxxxxxxx
    
        EXPLAIN SELECT * FROM users u1 LEFT JOIN (SELECT * FROM users WHERE sex = '0') u2 ON u1.uname = u2.uname;

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

执行结果Extra为`Using join buffer (Block Nested Loop)` 说明，需要进行嵌套循环计算, 这里每个表都有五条记录，内外表查询的type都为ALL。

问题在于 两个关联表join 使用 uname，关联字段均未建立索引，就会出现这种情况。

常见的优化方案是，在关联字段上添加索引，避免每次嵌套循环计算。

*  **Using index condition**
    
    查找使用了索引 (但是只使用了一部分,一般是指联合索引)，但是需要回表查询数.
    
        xxxxxxxxxx
    
        explain select * from L5 where c > 10 and d = '';

**Extra主要指标的含义(有时会同时出现)**

*  `using index` ：使用覆盖索引的时候就会出现
 *  `using where`：在查找使用索引的情况下，需要回表去查询所需的数据
 *  `using index condition`：查找使用了索引，但是需要回表查询数据
 *  `using index & using where`：查找使用了索引，但是需要的数据都在索引列中能找到，所以不需要回表查询数据

[d857c7da95a4448a9756de08295b0eb2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/9d0ccfb5d5824464a3df8858ae671a82.png
[4ad3ca6cd8c544ad84ad6e3e3acc79f4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/3b9fd75c74914e81bda132ca98aa9534.png
[42cf47d3f4a84fa6acbdebbb516208e2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/fc24063fb3514866aca447904ece09a4.png
[d388ad51885f4fcc81d1d4e7b21eb54a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/7c6fe23dcd984b818a58238b77a3b64f.png
[afd4119f8a9847ea999dd6c88747cc08.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/a5dd204cf2c24c4982a090e4b238caf9.png
[af60abbc54fa48f19b5b1710471f4c93.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/5287078a6de14a9ebc4f8f6609ff627d.png
[28cac383a8d14f9bb49057255c7c195d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/2f8e056ddd1d43dca55763bc018967d0.png
[9bfb861bfb1445458a2f39efd6534d00.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/6499299212674ba3b96d1e53d9070db0.png
[0a18e1145f3a4887a7142bedc24ed4cc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/26e5ad33015c4d258cfdd7182b37f6ee.png
[44a3c7e43d9f43f88a3326e14efddebe.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/2fdbd5b6cba445579a07d13c6644beeb.png
[1ce0b5ea029d474191ea5894b744ee94.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/e291bcadec094a5c9ecd259b88a4f481.png
[c64e96a32c9e464bbded0423ea749fea.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/0d1f5b6a80ad4b1d83437cb7b93973a3.png
[79b2b859c6ee4fa99f6d378331961761.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/aec6a99de770404cb451f5ae13413da5.png
[330a31f4deee4a89bf631c8e68079702.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/385b9475711c4f9994555435e02d9d73.png
[39c797ee3b8941cd9c32a0fe0290be1b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/57931149a39647b9b3428f2c15f4b254.png
[e298584abf8f45fbb89b3beb148cea25.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/5ec9d94bcf0e449eb60ade442445b445.png
[80adf018198448b99d3004de624b16da.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/421d18989064400fa0144f3cb699743e.png
[ef56f397d3624c14b9b17ab60daaf1fd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/82a0e88e906142429f56e8a9e51e336e.png
[8e166ee3c1cd424c865960f50925e54b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/27474954440c4011b4745ceb77a5d8b2.png
[b8c4b8f6e4c94376852edacc497ebaee.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/16fb60c1b6ab47c1bce4b299254ef3b8.png
[f0e51943496c494c8fc88c87cd4d2f7d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/bc9b727f6fe94038b2678535a3075d6f.png
[6230556bd78a4bceaec46671213287d4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/7cc2e8d367034c48a6346af2131ddadc.png
[7e10ece3607c473bbe48c3e07adb5d25.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/ca2345d43eb847ef948a3665df43409b.png
[579e1683fd8c46d7937f9c1980bce659.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/417472d8ceb444e5b4bb1d191964f3d2.png
[f341acbf46d44ddbacf0a9028c7d022a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/91a5b832282245d794da7fa7a85b1e66.png
[369af53c9c4b44679bbc2c9ff0a05b21.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/c03203bd60614c829bae9dd7a399c75a.png
[54afc4614e0b47a2b58fe206ee440996.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/0896c1f0c7bb4012853e7e5cfda7a73e.png
[0e140eef81ae4cf69afa2553301dd1ca.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/6d4c24172e2045aea4cd4aca8ec5d8a5.png
[a5e4fc70c5094dc28124892944fa82a2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/c6a4d47ee0744ff5b15c01adc4e540c7.png
[234c9a2041a24bfe9361e025c843ecd3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/1cc7e0da7c8a4c2580774913ce8e88bf.png
[b26edf3f312c4cadaf7f3f1e4c9a1896.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/07535547dd2444ec8820364a8b6ea91d.png
[421934ff72a64b0ead6e9aa6a0505aec.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/b2b5f51425f542fc985ecd8df696af18.png
[f576b33853584a3db7c1f45e3d22b742.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/181c1fe8153446b4808f327787532a38.png
[a7817d6b4e8e4fe58f2628b52800d51e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/cc10a41aac14472dadbed7a9219dfed0.png