聊聊索引失效的10种场景，太坑了

小咪咪 2024-03-25 18:03 48阅读 0赞

**目录**

[前言][Link 1]

[1. 准备工作][1.]

[1.1 创建user表][1.1 _user]

[1.2 插入数据][1.2]

[1.3 查看数据库版本][1.3]

[1.4 查看执行计划][1.4]

[2. 不满足最左匹配原则][2.]

[2.1 哪些情况索引有效？][2.1]

[2.2 哪些情况索引失效？][2.2]

[3. 使用了select \*][3. _select]

[4. 索引列上有计算][4.]

[5. 索引列用了函数][5.]

[6. 字段类型不同][6.]

[7. like左边包含%][7. like]

[8. 列对比][8.]

[9. 使用or关键字][9. _or]

[10. not in和not exists][10. not in_not exists]

[10.1 in关键字][10.1 in]

[10.2 exists关键字][10.2 exists]

[10.3 not in关键字][10.3 not in]

[10.4 not exists关键字][10.4 not exists]

[11. order by的坑][11. order by]

[11.1 哪些情况走索引？][11.1]

[11.2 哪些情况不走索引？][11.2]

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

### 前言 ###

不知道你在实际工作中，有没有遇到过下面的这两种情况：

*  明明在某个字段上加了索引，但实际上并没有生效。
 *  索引有时候生效了，有时候没有生效。

今天就跟大家一起聊聊，mysql数据库[索引失效][Link 2]的10种场景，给曾经踩过坑，或者即将要踩坑的朋友们一个参考。

![图片][574c967e8ca796768e2287b006bc0109.png]

### 1. 准备工作 ###

所谓空口无凭，如果我直接把索引失效的这些场景丢出来，可能没有任何说服力。

所以，我决定建表和造数据，给大家一步步演示效果，尽量做到有理有据。

我相信，如果大家耐心的看完这篇文章，一定会有很多收获的。

#### 1.1 创建user表 ####

创建一张user表，表中包含：`id`、`code`、`age`、`name`和`height`字段。

1.  ``CREATE TABLE `user` (``
2.  `` `id` int NOT NULL AUTO_INCREMENT,``
3.  `` `code` varchar(20) COLLATE utf8mb4_bin DEFAULT NULL,``
4.  `` `age` int DEFAULT '0',``
5.  `` `name` varchar(30) COLLATE utf8mb4_bin DEFAULT NULL,``
6.  `` `height` int DEFAULT '0',``
7.  `` `address` varchar(30) COLLATE utf8mb4_bin DEFAULT NULL,``
8.  ``PRIMARY KEY (`id`),``
9.  ``KEY `idx_code_age_name` (`code`,`age`,`name`),``
10. ``KEY `idx_height` (`height`)``
11. `) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin`

此外，还创建了三个索引：

*  `id`：数据库的主键
 *  `idx_code_age_name`：由code、age和name三个字段组成的联合索引。
 *  `idx_height`：普通索引

#### 1.2 插入数据 ####

为了方便给大家做演示，我特意向user表中插入了3条数据：

1.  `INSERT INTO sue.user (id, code, age, name, height) VALUES (1, '101', 21, '周星驰', 175,'香港');`
2.  `INSERT INTO sue.user (id, code, age, name, height) VALUES (2, '102', 18, '周杰伦', 173,'台湾');`
3.  `INSERT INTO sue.user (id, code, age, name, height) VALUES (3, '103', 23, '苏三', 174,'成都');`

周星驰和周杰伦是我偶像，在这里自恋了一次，把他们和我放到一起了。哈哈哈。

#### 1.3 [查看数据库版本][Link 3] ####

为了防止以后出现不必要的误会，在这里有必要查一下当前数据库的版本。不说版本就直接给结论，是耍流氓，哈哈哈。

select version();

查出当前的mysql版本号为：`8.0.21`

#### 1.4 查看执行计划 ####

在mysql中，如果你想查看某条sql语句是否使用了索引，或者已建好的索引是否失效，可以通过`explain`关键字，查看该sql语句的执行计划，来判断索引使用情况。

例如：

explain select * from user where id=1;

执行结果：

![图片][2e91b9faacf6c5cbef2c4cefeacf9c82.png]

从图中可以看出，由于id字段是主键，该sql语句用到了`主键索引`。

当然，如果你想更深入的了解explain关键字的用法，可以看看我的另一篇文章《[explain | 索引优化的这把绝世好剑，你真的会用吗？][explain _]》，里面更为详细的介绍。

### 2. 不满足[最左匹配原则][Link 4] ###

之前我已经给code、age和name这3个字段建好`联合索引`：idx\_code\_age\_name。

该索引字段的顺序是：

*  code
 *  age
 *  name

如果在使用联合索引时，没注意最左前缀原则，很有可能导致索引失效喔，不信我们一起往下看。

#### 2.1 哪些情况索引有效？ ####

先看看哪些情况下，能走索引。

1.  `explain select * from user`
2.  `where code='101';`

1.  `explain select * from user`
2.  `where code='101' and age=21`

1.  `explain select * from user`
2.  `where code='101' and age=21 and name='周星驰';`

执行结果：

![图片][9579ac3f524db859191b3e94c70fbd76.png]

上面三种情况，sql都能正常走索引。

其实还有一种比较特殊的场景：

1.  `explain select * from user`
2.  `where code = '101' and name='周星驰';`

执行结果：

![图片][cb70cd1ebae1af84b49c57acdb8bcb5b.png]

查询条件原本的顺序是：code、age、name，但这里只有code和name中间断层了，掉了age字段，这种情况也能走code字段上的索引。

看到这里，不知道聪明的你，有没有发现这样一个规律：**这4条sql中都有code字段，它是索引字段中的第一个字段，也就是最左边的字段。只要有这个字段在，该sql已经就能走索引。**

这就是我们所说的`最左匹配原则`。

#### 2.2 哪些情况索引失效？ ####

前面我已经介绍过，建立了联合索引后，在查询条件中有哪些情况索引是有效的。

接下来，我们重点看看哪些情况下索引会失效。

1.  `explain select * from user`
2.  `where age=21;`

1.  `explain select * from user`
2.  `where name='周星驰';`

1.  `explain select * from user`
2.  `where age=21 and name='周星驰';`

执行结果：

![图片][2a7f7a887b9d8080ab42fd253efbbeff.png]

从图中看出这3种情况下索引确实失效了。

说明以上3种情况不满足最左匹配原则，说白了是因为查询条件中，没有包含给定字段最左边的索引字段，即字段code。

### 3. 使用了select \* ###

在《阿里巴巴开发手册》中明确说过，查询sql中禁止使用`select *` 。

那么，你知道为什么吗？

废话不多说，按照国际惯例先上一条sql：

1.  `explain`
2.  `select * from user where name='苏三';`

执行结果：

![图片][9d17014aa70f191f0125e6683d0dffa4.png]

在该sql中用了`select *`，从执行结果看，走了全表扫描，没有用到任何索引，查询效率是非常低的。

如果查询的时候，只查我们真正需要的列，而不查所有列，结果会怎么样？

非常快速的将上面的sql改成只查了code和name列，太easy了：

1.  `explain`
2.  `select code,name from user`
3.  `where name='苏三';`

执行结果：

![图片][b5fb671aa9c05834d7923f80675a74c4.png]

从图中执行结果不难看出，该sql语句这次走了`全索引扫描`，比`全表扫描`效率更高。

其实这里用到了：`覆盖索引`。

如果select语句中的查询列，都是索引列，那么这些列被称为覆盖索引。这种情况下，查询的相关字段都能走索引，索引查询效率相对来说更高一些。

而使用`select *`查询所有列的数据，大概率会查询非索引列的数据，非索引列不会走索引，查询效率非常低。

### 4. 索引列上有计算 ###

介绍本章节内容前，先跟大家一起回顾一下，根据id查询数据的sql语句：

explain select * from user where id=1;

执行结果：

![图片][18ad15550df88877e6a9b4c66863c40d.png]

从图中可以看出，由于id字段是主键，该sql语句用到了`主键索引`。

但如果id列上面有计算，比如：

explain select * from user where id+1=2;

执行结果：

![图片][cee7f25aa6422d8eb69956ee6a5892e8.png]

从上图中的执行结果，能够非常清楚的看出，该id字段的主键索引，在有计算的情况下失效了。

### 5. 索引列用了函数 ###

有时候我们在某条sql语句的查询条件中，需要使用函数，比如：截取某个字段的长度。

假如现在有个需求：想查出所有身高是17开头的人，如果sql语句写成这样：

explain select * from user  where height=17;

该sql语句确实用到了普通索引：

![图片][71542e5de5e0335e9d3c183fe28d961f.png]

但该sql语句肯定是有问题的，因为它只能查出身高正好等于17的，但对于174这种情况，它没办法查出来。

为了满足上面的要求，我们需要把sql语句稍稍改造了一下：

explain select * from user  where SUBSTR(height,1,2)=17;

这时需要用到`SUBSTR`函数，用它截取了height字段的前面两位字符，从第一个字符开始。

执行结果：

![图片][5c4b038c59ff38addbcf342d8a8f8c8d.png]

你有没有发现，在使用该函数之后，该sql语句竟然走了全表扫描，索引失效了。

### 6. 字段类型不同 ###

在sql语句中因为字段类型不同，而导致索引失效的问题，很容易遇到，可能是我们日常工作中最容易忽略的问题。

到底怎么回事呢？

请大家注意观察一下t\_user表中的code字段，它是`varchar`字符类型的。

在sql语句中查询数据时，查询条件我们可以写成这样：

1.  `explain`
2.  `select * from user where code="101";`

执行结果：

![图片][c21aed98c8a30794b3148865f09a1e85.png]

从上图中看到，该code字段走了索引。

> 温馨提醒一下，查询字符字段时，用双引号`“`和单引号`'`都可以。

但如果你在写sql时，不小心把引号弄掉了，把sql语句变成了：

1.  `explain`
2.  `select * from user where code=101;`

执行结果：

![图片][e7b28278bea30eae165d5488c62fa70b.png]

你会惊奇的发现，该sql语句竟然变成了全表扫描。因为少写了引号，这种小小的失误，竟然让code字段上的索引失效了。

这时你心里可能有一万个为什么，其中有一个肯定是：为什么索引会失效呢？

答：因为code字段的类型是varchar，而传参的类型是int，两种类型不同。

此外，还有一个有趣的现象，如果int类型的height字段，在查询时加了引号条件，却还可以走索引：

1.  `explain select * from user`
2.  `where height='175';`

执行结果：

![图片][5b50253b1c5c2ca7576a72557f9cba18.png]

从图中看出该sql语句确实走了索引。int类型的参数，不管在查询时加没加引号，都能走索引。

这是变魔术吗？这不科学呀。

答：mysql发现如果是`int`类型字段作为查询条件时，它会自动将该字段的传参进行`隐式转换`，把字符串转换成int类型。

mysql会把上面列子中的字符串175，转换成数字175，所以仍然能走索引。

接下来，看一个更有趣的sql语句：

select 1 + '1';

它的执行结果是2，还是11呢？

好吧，不卖关子了，直接公布答案执行结果是2。

mysql自动把字符串1，转换成了int类型的1，然后变成了：1+1=2。

但如果你确实想拼接字符串该怎么办？

答：可以使用`concat`关键字。

具体拼接sql如下：

select concat(1,'1');

接下来，关键问题来了：**为什么字符串类型的字段，传入了int类型的参数时索引会失效呢？**

答：根据mysql官网上解释，字符串'1'、' 1 '、'1a'都能转换成int类型的1，也就是说可能会出现多个字符串，对应一个int类型参数的情况。那么，mysql怎么知道该把int类型的1转换成哪种字符串，用哪个索引快速查值?

感兴趣的小伙伴可以再看看官方文档：`https://dev.mysql.com/doc/refman/8.0/en/type-conversion.html`

### 7. like左边包含% ###

模糊查询，在我们日常的工作中，使用频率还是比较高的。

比如现在有个需求：想查询姓李的同学有哪些?

使用`like`语句可以很快的实现：

select * from user where name like '李%';

但如果like用的不好，就可能会出现性能问题，因为有时候它的索引会失效。

不信，我们一起往下看。

目前like查询主要有三种情况：

*  like '%a'
 *  like 'a%'
 *  like '%a%'

假如现在有个需求：想查出所有code是10开头的用户。

这个需求太简单了吧，sql语句如下：

1.  `explain select * from user`
2.  `where code like '10%';`

执行结果：

![图片][a673f6c3caca8089499515b2b0aa68ce.png]

图中看出这种`%`在`10`右边时走了索引。

而如果把需求改了：想出现出所有code是1结尾的用户。

查询sql语句改为：

1.  `explain select * from user`
2.  `where code like '%1';`

执行结果：

![图片][220a2b050da72b99b1edb64b27d8bb10.png]

从图中看出这种`%`在`1`左边时，code字段上索引失效了，该sql变成了全表扫描。

此外，如果出现以下sql：

1.  `explain select * from user`
2.  `where code like '%1%';`

该sql语句的索引也会失效。

下面用一句话总结一下规律：当`like`语句中的`%`，出现在查询条件的左边时，索引会失效。

那么，为什么会出现这种现象呢？

答：其实很好理解，索引就像字典中的目录。一般目录是按字母或者拼音从小到大，从左到右排序，是有顺序的。

我们在查目录时，通常会先从左边第一个字母进行匹对，如果相同，再匹对左边第二个字母，如果再相同匹对其他的字母，以此类推。

通过这种方式我们能快速锁定一个具体的目录，或者缩小目录的范围。

但如果你硬要跟目录的设计反着来，先从字典目录右边匹配第一个字母，这画面你可以自行脑补一下，你眼中可能只剩下绝望了，哈哈。

### 8. 列对比 ###

上面的内容都是常规需求，接下来，来点不一样的。

假如我们现在有这样一个需求：过滤出表中某两列值相同的记录。比如user表中id字段和height字段，查询出这两个字段中值相同的记录。

这个需求很简单，sql可以这样写：

1.  `explain select * from user`
2.  `where id=height`

执行结果：

![图片][d8271285cb5aef5f99fc3edd0303db80.png]

意不意外，惊不惊喜？索引失效了。

为什么会出现这种结果？

id字段本身是有主键索引的，同时height字段也建了普通索引的，并且两个字段都是int类型，类型是一样的。

但如果把两个单独建了索引的列，用来做列对比时索引会失效。

感兴趣的朋友可以找我私聊。

### 9. 使用or关键字 ###

我们平时在写查询sql时，使用`or`关键字的场景非常多，但如果你稍不注意，就可能让已有的索引失效。

不信一起往下面看。

某天你遇到这样一个需求：想查一下id=1或者height=175的用户。

你三下五除二就把sql写好了：

1.  `explain select * from user`
2.  `where id=1 or height='175';`

执行结果：

![图片][7f1c65b1f009619804c3bab2acf707a9.png]

没错，这次确实走了索引，恭喜被你蒙对了，因为刚好id和height字段都建了索引。

但接下来的一个夜黑风高的晚上，需求改了：除了前面的查询条件之后，还想加一个address='成都'。

这还不简单，sql走起：

1.  `explain select * from user`
2.  `where id=1 or height='175' or address='成都';`

执行结果：

![图片][64516f5bafeeff785503216d00a46816.png]

结果悲剧了，之前的索引都失效了。

你可能一脸懵逼，为什么？我做了什么？

答：因为你最后加的address字段没有加索引，从而导致其他字段的索引都失效了。

> 注意：如果使用了`or`关键字，那么它前面和后面的字段都要加索引，不然所有的索引都会失效，这是一个大坑。

### 10. not in和not exists ###

在我们日常工作中用得也比较多的，还有范围查询，常见的有：

*  in
 *  exists
 *  not in
 *  not exists
 *  between and

今天重点聊聊前面四种。

#### 10.1 in关键字 ####

假如我们想查出height在某些范围之内的用户，这时sql语句可以这样写：

1.  `explain select * from user`
2.  `where height in (173,174,175,176);`

执行结果：

![图片][8ce33e0fb7e8097ad9e6483b15b1a0f2.png]

从图中可以看出，sql语句中用`in`关键字是走了索引的。

#### 10.2 exists关键字 ####

有时候使用`in`关键字时性能不好，这时就能用`exists`关键字优化sql了，该关键字能达到in关键字相同的效果：

1.  `explain select * from user t1`
2.  `where exists (select 1 from user t2 where t2.height=173 and t1.id=t2.id)`

执行结果：

![图片][4d3b70cf44840b1681fb13735fe3e897.png]

从图中可以看出，用`exists`关键字同样走了索引。

#### 10.3 not in关键字 ####

上面演示的两个例子是正向的范围，即在某些范围之内。

那么反向的范围，即不在某些范围之内，能走索引不？

话不多说，先看看使用`not in`的情况：

1.  `explain select * from user`
2.  `where height not in (173,174,175,176);`

执行结果：

![图片][e09022301fdaa815029acc2558474834.png]

你没看错，索引失效了。

看如果现在需求改了：想查一下id不等于1、2、3的用户有哪些，这时sql语句可以改成这样：

1.  `explain select * from user`
2.  `where id not in (173,174,175,176);`

执行结果：

![图片][5b9f50b931b6edb080bf73ea176f382a.png]

你可能会惊奇的发现，主键字段中使用not in关键字查询数据范围，任然可以走索引。而普通索引字段使用了not in关键字查询数据范围，索引会失效。

#### 10.4 not exists关键字 ####

除此之外，如果sql语句中使用`not exists`时，索引也会失效。具体sql语句如下：

1.  `explain select * from user t1`
2.  `where not exists (select 1 from user t2 where t2.height=173 and t1.id=t2.id)`

执行结果：

![图片][125e2491e1a3bfd35b58fe48e11f8d32.png]

从图中看出sql语句中使用not exists关键后，t1表走了全表扫描，并没有走索引。

### 11. order by的坑 ###

在sql语句中，对查询结果进行排序是非常常见的需求，一般情况下我们用关键字：`order by`就能搞定。

但我始终觉得order by挺难用的，它跟`where`或者`limit`关键字有很多千丝万缕的联系，一不小心就会出问题。

Let go

#### 11.1 哪些情况走索引？ ####

首先当然要温柔一点，一起看看order by的哪些情况可以走索引。

我之前说过，在code、age和name这3个字段上，已经建了联合索引：idx\_code\_age\_name。

11.1.1 满足最左匹配原则

order by后面的条件，也要遵循联合索引的最左匹配原则。具体有以下sql：

1.  `explain select * from user`
2.  `order by code limit 100;`
3.  
4.  `explain select * from user`
5.  `order by code,age limit 100;`
6.  
7.  `explain select * from user`
8.  `order by code,age,name limit 100;`

执行结果：

![图片][f3243854f6b930bb88fe4a6ca7170876.png]

从图中看出这3条sql都能够正常走索引。

除了遵循最左匹配原则之外，有个非常关键的地方是，后面还是加了`limit`关键字，如果不加它索引会失效。

11.1.2 配合where一起使用

order by还能配合where一起遵循最左匹配原则。

1.  `explain select * from user`
2.  `where code='101'`
3.  `order by age;`

执行结果：

![图片][43f5f4dc5de349e562aac34b15d0d12b.png]

code是联合索引的第一个字段，在where中使用了，而age是联合索引的第二个字段，在order by中接着使用。

假如中间断层了，sql语句变成这样，执行结果会是什么呢？

1.  `explain select * from user`
2.  `where code='101'`
3.  `order by name;`

执行结果：

![图片][b19379e5fac63694eca6cd4c8b9ceaed.png]

虽说name是联合索引的第三个字段，但根据最左匹配原则，该sql语句依然能走索引，因为最左边的第一个字段code，在where中使用了。只不过order by的时候，排序效率比较低，需要走一次`filesort`排序罢了。

11.1.3 相同的排序

order by后面如果包含了联合索引的多个排序字段，只要它们的排序规律是相同的（要么同时升序，要么同时降序），也可以走索引。

具体sql如下：

1.  `explain select * from user`
2.  `order by code desc,age desc limit 100;`

执行结果：

![图片][3107531bd035c904335c5575d0305066.png]

该示例中order by后面的code和age字段都用了降序，所以依然走了索引。

11.1.4 两者都有

如果某个联合索引字段，在where和order by中都有，结果会怎么样？

1.  `explain select * from user`
2.  `where code='101'`
3.  `order by code, name;`

执行结果：

![图片][da960ea9e60f1fd53d8e61a2ad67dded.png]

code字段在where和order by中都有，对于这种情况，从图中的结果看出，还是能走了索引的。

#### 11.2 哪些情况不走索引？ ####

前面介绍的都是正面的用法，是为了让大家更容易接受下面反面的用法。

好了，接下来，重点聊聊order by的哪些情况下不走索引？

11.2.1 没加where或limit

如果order by语句中没有加where或limit关键字，该sql语句将不会走索引。

1.  `explain select * from user`
2.  `order by code, name;`

执行结果：

![图片][f72be1ba45ff3b3761a7c3cdd3ab3965.png]

从图中看出索引真的失效了。

11.2.2 对不同的索引做order by

前面介绍的基本都是联合索引，这一个索引的情况。但如果对多个索引进行order by，结果会怎么样呢？

1.  `explain select * from user`
2.  `order by code, height limit 100;`

执行结果：

![图片][ed8332e62bbcdb9e32662f4d37f20e1c.png]

从图中看出索引也失效了。

11.2.3 不满足最左匹配原则

前面已经介绍过，order by如果满足最左匹配原则，还是会走索引。下面看看，不满足最左匹配原则的情况：

1.  `explain select * from user`
2.  `order by name limit 100;`

执行结果：

![图片][793afe7b7bcb1b7a80f8e049206df3b3.png]

name字段是联合索引的第三个字段，从图中看出如果order by不满足最左匹配原则，确实不会走索引。

11.2.4 不同的排序

前面已经介绍过，如果order by后面有一个联合索引的多个字段，它们具有相同排序规则，那么会走索引。

但如果它们有不同的排序规则呢？

1.  `explain select * from user`
2.  `order by code asc,age desc limit 100;`

执行结果：

![图片][744ea6273cb918c26b2f37d42d1c0bd4.png]

从图中看出，尽管order by后面的code和age字段遵循了最左匹配原则，但由于一个字段是用的升序，另一个字段用的降序，最终会导致索引失效。

[Link 1]: https://blog.csdn.net/guoqi_666/article/details/122484441#t0
[1.]: https://blog.csdn.net/guoqi_666/article/details/122484441#t1
[1.1 _user]: https://blog.csdn.net/guoqi_666/article/details/122484441#t2
[1.2]: https://blog.csdn.net/guoqi_666/article/details/122484441#t3
[1.3]: https://blog.csdn.net/guoqi_666/article/details/122484441#t4
[1.4]: https://blog.csdn.net/guoqi_666/article/details/122484441#t5
[2.]: https://blog.csdn.net/guoqi_666/article/details/122484441#t6
[2.1]: https://blog.csdn.net/guoqi_666/article/details/122484441#t7
[2.2]: https://blog.csdn.net/guoqi_666/article/details/122484441#t8
[3. _select]: https://blog.csdn.net/guoqi_666/article/details/122484441#t9
[4.]: https://blog.csdn.net/guoqi_666/article/details/122484441#t10
[5.]: https://blog.csdn.net/guoqi_666/article/details/122484441#t11
[6.]: https://blog.csdn.net/guoqi_666/article/details/122484441#t12
[7. like]: https://blog.csdn.net/guoqi_666/article/details/122484441#t13
[8.]: https://blog.csdn.net/guoqi_666/article/details/122484441#t14
[9. _or]: https://blog.csdn.net/guoqi_666/article/details/122484441#t15
[10. not in_not exists]: https://blog.csdn.net/guoqi_666/article/details/122484441#t16
[10.1 in]: https://blog.csdn.net/guoqi_666/article/details/122484441#t17
[10.2 exists]: https://blog.csdn.net/guoqi_666/article/details/122484441#t18
[10.3 not in]: https://blog.csdn.net/guoqi_666/article/details/122484441#t19
[10.4 not exists]: https://blog.csdn.net/guoqi_666/article/details/122484441#t20
[11. order by]: https://blog.csdn.net/guoqi_666/article/details/122484441#t21
[11.1]: https://blog.csdn.net/guoqi_666/article/details/122484441#t22
[11.2]: https://blog.csdn.net/guoqi_666/article/details/122484441#t23
[Link 2]: https://so.csdn.net/so/search?q=%E7%B4%A2%E5%BC%95%E5%A4%B1%E6%95%88&spm=1001.2101.3001.7020
[574c967e8ca796768e2287b006bc0109.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/9f6e44ad8cd64379a15ea3a4c366ee4a.png
[Link 3]: https://so.csdn.net/so/search?q=%E6%9F%A5%E7%9C%8B%E6%95%B0%E6%8D%AE%E5%BA%93%E7%89%88%E6%9C%AC&spm=1001.2101.3001.7020
[2e91b9faacf6c5cbef2c4cefeacf9c82.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/c8357ac7c7134bd9a71b8fd9b2e1b3cc.png
[explain _]: https://mp.weixin.qq.com/s?__biz=MzkwNjMwMTgzMQ==&mid=2247490262&idx=1&sn=a67f610afa984ecca130a54a3be453ab&scene=21#wechat_redirect
[Link 4]: https://so.csdn.net/so/search?q=%E6%9C%80%E5%B7%A6%E5%8C%B9%E9%85%8D%E5%8E%9F%E5%88%99&spm=1001.2101.3001.7020
[9579ac3f524db859191b3e94c70fbd76.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/0dabd416aab54388ab54a4aa7e998f91.png
[cb70cd1ebae1af84b49c57acdb8bcb5b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/85a997b12add439d84c55a3b6e75d557.png
[2a7f7a887b9d8080ab42fd253efbbeff.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/0411d875a81b4d50930c5872ecd0453c.png
[9d17014aa70f191f0125e6683d0dffa4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/e786240ef1d242dcbad5081b3b8c1746.png
[b5fb671aa9c05834d7923f80675a74c4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/c38550e6f4b3489aa4144e54798448f7.png
[18ad15550df88877e6a9b4c66863c40d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/f12587775e2246eb9e26da6bcdbba970.png
[cee7f25aa6422d8eb69956ee6a5892e8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/8abb2f35ce05432693b37425278411ce.png
[71542e5de5e0335e9d3c183fe28d961f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/b4e993f5dbd342d39984739c9d72e2b0.png
[5c4b038c59ff38addbcf342d8a8f8c8d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/a4d0ab8446a543d19a3e8238da72bb17.png
[c21aed98c8a30794b3148865f09a1e85.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/dad0220b2d35410590421a33b174a81d.png
[e7b28278bea30eae165d5488c62fa70b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/c2b718396dd74844891bb83aae2b7d2e.png
[5b50253b1c5c2ca7576a72557f9cba18.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/f71f2e237b2a48f8acc3aa4ce29d627e.png
[a673f6c3caca8089499515b2b0aa68ce.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/170869f97b4841cab324a96172f32d51.png
[220a2b050da72b99b1edb64b27d8bb10.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/f074905cbb3f4cf89b24e90d4bc2d1d9.png
[d8271285cb5aef5f99fc3edd0303db80.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/b0883a02f0384ecebc984bc829e2579a.png
[7f1c65b1f009619804c3bab2acf707a9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/06e5e7030f714147bd92320ccd3ae5e4.png
[64516f5bafeeff785503216d00a46816.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/9d80cd0d1be64ec7ad645922bb2892d8.png
[8ce33e0fb7e8097ad9e6483b15b1a0f2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/a84e5ee4c396409fbcc2c6b055b79fb6.png
[4d3b70cf44840b1681fb13735fe3e897.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/637951ff48154da68abdb311e1590f83.png
[e09022301fdaa815029acc2558474834.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/70aad316f43d4e0dba4631f242ddfdd7.png
[5b9f50b931b6edb080bf73ea176f382a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/059ad34398324d7cb83ba4f318892888.png
[125e2491e1a3bfd35b58fe48e11f8d32.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/42fe5c95348a4c8a9434c99c3f9f6111.png
[f3243854f6b930bb88fe4a6ca7170876.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/1ab9fb7b215e4793af68318f883ac8e9.png
[43f5f4dc5de349e562aac34b15d0d12b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/21d6d581466b40b1ba833e11a5f4e8f9.png
[b19379e5fac63694eca6cd4c8b9ceaed.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/38249b05d6ab48ccbfa8215d1526e0ee.png
[3107531bd035c904335c5575d0305066.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/923face7a6b14caf9cf6a4379453b63e.png
[da960ea9e60f1fd53d8e61a2ad67dded.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/3fed82b3d26941ac80c1263ffc43e81c.png
[f72be1ba45ff3b3761a7c3cdd3ab3965.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/b693a239f62f4ae88e577bc83dc6b3fd.png
[ed8332e62bbcdb9e32662f4d37f20e1c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/e4e20aa39d6b47e7aa2d427d53601ece.png
[793afe7b7bcb1b7a80f8e049206df3b3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/9d4bc6a3725049bc810a47d7fbdb12bb.png
[744ea6273cb918c26b2f37d42d1c0bd4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/23dc130ffbc34273b8fbb46cd7feacb1.png