MySQL——存储引擎与索引应用

骑猪看日落 2024-03-17 11:12 71阅读 0赞

#### 文章目录 ####

*  一、 存储引擎
 *   *  1.1 MySQL结构
     *  1.2 存储引擎简介
     *  1.3 存储引擎特点
     *   *  1.3.1 InnoDB
         *   *  1.3.1.1 InnoDB 基本介绍
             *  1.3.1.2 InnoDB 逻辑存储结构
         *  1.3.2 MyISAM
         *  1.3.3 Memory
     *  1.4 三种引擎特点及区别
     *  1.5 存储引擎选择
 *  二、 索引 - 重点
 *   *  2.1 介绍
     *  2.2 索引结构
     *   *  2.2.1 B-Tree 多路平衡二叉树
         *  2.2.2 B+Tree
         *  2.2.3 Hash结构
         *  2.2.4 思考
     *  2.3 索引分类
     *  2.4.0 数据准备
     *  2.4 索引语法
     *  2.5 SQL性能分析
     *   *  2.5.1 SQL执行频率
         *  2.5.2 慢查询日志
         *  2.5.3 profile 详情
         *  2.5.4 explain 执行计划
     *  2.6 使用规则
     *   *  2.6.1 最左前缀法则
         *  2.6.2 索引失效情况
         *  2.6.3 SQL 提示
         *  2.6.4 覆盖索引
         *  2.6.5 前缀索引
         *  2.6.6 单列索引与联合索引
     *  2.7 涉及原则

## 一、 存储引擎 ##

### 1.1 MySQL结构 ###

![image-20230523140643048][]

*  **连接层**

**最上层是一些客户端和链接服务**，包含本地sock 通信和大多数基于客户端/服务端工具实现的类似于TCP/IP的通信。

**主要完成一些类似于连接处理、授权认证、及相关的安全方案**。在该层上引入了线程池的概念，为通过认证安全接入的客户端提供线程。同样在该层上可以实现基于SSL的安全链接。**服务器也会为安全接入的每个客户端验证它所具有的操作权限。**

*  **服务层**

第二层架构**主要完成大多数的核心服务功能，如SQL接口，并完成缓存的查询，SQL的分析和优化，部分内置函数的执行。**

**所有跨存储引擎的功能也在这一层实现，如 过程、函数等**。在该层，服务器会解析查询并创建相应的内部解析树，并对其完成相应的优化如确定表的查询的顺序，**是否利用索引**等，最后生成相应的执行操作。如果是select语句，服务器还会查询内部的缓存，如果缓存空间足够大，这样在解决大量读操作的环境中能够很好的提升系统的性能。

*  **引擎层**

存储引擎层， **存储引擎真正的负责了MySQL中数据的存储和提取**，**服务器通过API和存储引擎进行通信。**

**不同的存储引擎具有不同的功能，这样我们可以根据自己的需要，来选取合适的存储引擎**。数据库中的索引是在存储引擎层实现的。

**索引是在存储引擎层实现的，不同的存储引擎，索引存储结构是不一样的**

**innodb 存储引擎是 MySQL 5.5 之后的默认引擎**

*  **存储层**

**主要是将数据存储在文件系统之上，并完成与存储引擎的交互**

控制数据库中的数据该如何保存、如何取，如何组织，最终数据库中的数据时存储在磁盘当中的

数据存储层， 主要是将数据(如: redolog、undolog、数据、索引、二进制日志、错误日志、查询日志、慢查询日志等)存储在文件系统之上，并完成与存储引擎的交

### 1.2 存储引擎简介 ###

**存储引擎就是存储数据、建立索引、更新/查询数据等技术的实现方式。存储引擎是基于表的，而不是基于库的，所以存储引擎也可被称为表类型**

> 创建表时没有指定存储引擎，会赋予一个默认的存储引擎。
> 
> **innodb 存储引擎是 MySQL 5.5 之后的默认引擎**
> 
> 比如查看之前创建的表：
> 
>     show create table account;
> 
>     CREATE TABLE `account` (
>       `id` int NOT NULL AUTO_INCREMENT COMMENT 'ID',
>       `name` varchar(10) DEFAULT NULL COMMENT '姓名',
>       `money` double(10,2) DEFAULT NULL COMMENT '余额',
>       PRIMARY KEY (`id`)
>     ) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='账户表'

*  **建表时指定存储引擎**

CREATE TABLE 表名(
    字段1 字段1类型 [ COMMENT 字段1注释 ] ,
    ......
    字段n 字段n类型 [COMMENT 字段n注释 ]
    ) ENGINE = INNODB [ COMMENT 表注释 ] ;

*  **查询当前数据库支持的存储引擎**

show engines;

InnoDB 被标识 “DEFAULT”，说明是默认的

![image-20230523143203137][]

### 1.3 存储引擎特点 ###

#### 1.3.1 InnoDB ####

##### 1.3.1.1 InnoDB 基本介绍 #####

InnoDB是一种**兼顾高可靠性和高性能的通用存储引擎**，在 MySQL 5.5 之后，InnoDB是默认的MySQL 存储引擎。

**特点**

*  DML操作（增、删、改）遵循ACID模型（事务四大特性），**支持事务**
 *  **行级锁**，提高并发访问性能；
 *  支持**外键**FOREIGN KEY约束，保证数据的完整性和正确性；

**涉及磁盘文件**

*  **xxx.ibd**：xxx代表的是表名，innoDB引擎的每张表都会对应这样一个表空间文件，**存储该表的表结构（frm-早期的 、sdi-新版的）、数据和索引。**

比如account表，存储引擎使用的是InnoDB，那account就会对应一个磁盘文件account.ibd

> **参数：innodb\_file\_per\_table**
> 
> 此参数决定是多张表共享一个表空间文件还是每一个表对应于一个表空间文件
> 
> **如果该参数开启，代表对于InnoDB引擎的表，每一张表都对应一个ibd文件**
> 
> 在MySQL8.0中是打开的
> 
>     innodb_file_per_table
> 
> ![image-20230523144615344][]
> 
> 可以观察一下MySQL安装目录下的data目录，下面中的每一个目录都是一个数据库，随便点进去一个，比如“itcast”数据库
> 
> ![image-20230523144858938][]
> 
> **每一个ibd文件就对应一张表**，在这个ibd文件中不仅存放表结构、数据，还会存放该表对应的索引信息
> 
> 而该文件是基于二进制存储的，不能直接基于记事本打开，我们可以使用mysql提供的一个\*\*指令 ibd2sdi \*\*，通过该指令就可以从ibd文件中提取sdi信息，而sdi数据字典信息中就包含该表的表结构
> 
> 比如 “ ibd2sdi account.ibd ”
> 
> ![image-20230523144946160][]

##### 1.3.1.2 InnoDB 逻辑存储结构 #####

*  **TableSpace**： 表空间

ibd文件属于表空间文件，在表空间中可以包含多个Segment段

*  **Segment**： 段

表空间是由各个段组成的，常见的段有数据段、索引段、回滚段等

InnoDB中对于段的管理，都是引擎自身完成，不需要人为对其控制。  
一个段中包含多个区。

*  **Extent**： 区

**区是表空间的单元结构，每个区的大小为1M。**

默认情况下， InnoDB存储引擎页大小为16K， 即一个区中一共有64个连续的页

*  **Page**： 页

我们存储的一行一行的内容

页是组成区的最小单元，**页也是InnoDB存储引擎磁盘管理的最小单元**，每个页的大小默认为 16KB。为了保证页的连续性，InnoDB 存储引擎每次从磁盘申请 4-5 个区。

*  **Row**： 行

InnoDB 存储引擎是面向行的，也就是说数据是按行进行存放的，在每一行中除了定义表时所指定的字段以外，还包含两个隐藏字段(后面会详细介绍)。

![image-20230523150638909][]

#### 1.3.2 MyISAM ####

MyISAM是MySQL早期的默认存储引擎

**特点**

*  不支持事务，不支持外键
 *  支持表锁，不支持行锁
 *  访问速度快

**文件**

*  xxx.sdi：存储表结构信息
 *  xxx.MYD: 存储数据
 *  xxx.MYI: 存储索引

#### 1.3.3 Memory ####

Memory引擎的表数据时存储在内存中，由于受到硬件问题，或者断电影响，**只能将这些表作为临时表或缓存使用**。

**特点**

*  内存存放，访问速度快
 *  hash索引（默认）

**文件**

xxx.sdi： 存储表结构信息

因为存放在内存当中，所以只需要一个文件即可

### 1.4 三种引擎特点及区别 ###

![image-20230523164638566][]

*  **InnoDB引擎 和MyISAM引擎的区别？**

①. InnoDB引擎, 支持事务, 而MyISAM不支持。

②. InnoDB引擎, 支持行锁和表锁, 而MyISAM仅支持表锁, 不支持行锁。

③. InnoDB引擎, 支持外键, 而MyISAM是不支持的。

### 1.5 存储引擎选择 ###

*  **InnoDB**
    
    是Mysql的默认存储引擎，支持事务、外键。
    
    如果应用对事务的完整性有比较高的要求，在并发条件下要求数据的一致性，数据操作除了插入和查询之外，还包含很多的更新、删除操作，那么InnoDB存储引擎是比较合适的选择。
 *  **MyISAM**

如果应用是以读操作和插入操作为主，只有很少的更新和删除操作，**并且对事务的完整性、并发性要求不是很高**，那么选择这个存储引擎是非常合适的。

*  **MEMORY**

**被当前比较流行的Redis替代了**

将所有数据保存在内存中，访问速度快，**通常用于临时表及缓存**。MEMORY的缺陷就是对表的大小有限制，太大的表无法缓存在内存中，而且无法保障数据的安全性。

## 二、 索引 - 重点 ##

### 2.1 介绍 ###

**索引**：是帮助MySQL高效获取数据的数据结构（有序）。

在数据之外，数据库系统还维护着满足特定查找算法的数据结构，**这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法，这种数据结构就是索引**

> **有无索引在查询的时候有什么区别？**
> 
>  *  **无索引**
> 
> 如左侧所示，没有索引，如果我们想找到age=48的数据，只能从上往下一个一个比对
> 
>  *  **有索引**
> 
> 如右图所示，将表中的数据形成一个最优二叉树，在下图中的数据中，只需要匹配3次就可以匹配到age=45的数据
> 
> 此二叉树并不是真实的索引结构，只是以二叉树为例做出演示
> 
> [数据结构与算法——赫夫曼树基本实现][Link 1]
> 
> ![image-20230523183533929][]

**优点**

*  提高数据检索效率，降低数据库IO成本 （**提高查询效率**）
 *  通过索引列对数据进行排序，降低数据排序成本，抵消CPU消耗（**提高排序效率**）

**劣势**

*  索引列也是要占用空间的 （这个缺点也可以不考虑，因为磁盘比较便宜）
 *  索引大大提高了查询效率，同时也降低更新表的速度，如对表进行insert、update、delete时，效率降低

### 2.2 索引结构 ###

索引是在第三层存储引擎层实现的，也就是说根据存储引擎的不同，索引的数据结构也不相同

<table> 
 <thead> 
  <tr> 
   <th><strong>索引结构</strong></th> 
   <th><strong>描述</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><strong>B+Tree 索引</strong></td> 
   <td>最常见的索引类型，大部分引擎都支持 B+ 树索引</td> 
  </tr> 
  <tr> 
   <td>Hash 索引</td> 
   <td>底层数据结构是用哈希表实现的, <strong>只有精确匹配索引列的查询才有效, 不支持范围查询</strong></td> 
  </tr> 
  <tr> 
   <td>R-tree(空间索引）</td> 
   <td>空间索引是MyISAM引擎的一个特殊索引类型，主要用于地理空间数据类型，通常使用较少</td> 
  </tr> 
  <tr> 
   <td>Full-text(全文索引)</td> 
   <td>是一种通过建立倒排索引,快速匹配文档的方式。类似于Lucene,Solr,ES</td> 
  </tr> 
 </tbody> 
</table>

**我们平常所说的索引，如果没有特别指明，都是指B+树结构组织的索引。**

<table> 
 <thead> 
  <tr> 
   <th><strong>索引</strong></th> 
   <th><strong>InnoDB</strong></th> 
   <th><strong>MyISAM</strong></th> 
   <th><strong>Memory</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>B+tree索引</td> 
   <td>支持</td> 
   <td>支持</td> 
   <td>支持</td> 
  </tr> 
  <tr> 
   <td>Hash 索引</td> 
   <td>不支持</td> 
   <td>不支持</td> 
   <td>支持</td> 
  </tr> 
  <tr> 
   <td>R-tree 索引</td> 
   <td>不支持</td> 
   <td>支持</td> 
   <td>不支持</td> 
  </tr> 
  <tr> 
   <td>Full-text</td> 
   <td>5.6版本之后支持</td> 
   <td>支持</td> 
   <td>不支持</td> 
  </tr> 
 </tbody> 
</table>

#### 2.2.1 B-Tree 多路平衡二叉树 ####

二叉树： 一个结点下面最多包含两个子节点

**资料**： [ 数据结构与算法——二叉树遍历、查找、删除、顺序存储二叉树、线索化二叉树][Link 2]

**二叉树缺点**：

*  **顺序插入时，会形成一个链表，查询性能大大降低**
 *  **大数据情况下，层级越深，检索速度越慢**

为了解决这两种情况，我们采取一下**措施**

*  **对于第一种情况将二叉树转变成红黑树**

红黑树是一个自平衡二叉树，但是仍存在层级越深，检索速度越慢的问题

![image-20230523195036558][]

*  **对于第二种情况我们使用 B-Tree 多路平衡二叉树**

以一颗最大度数（max-degree）为5（5阶）的B-Tree为例（每个结点最多存储4个Key，5个指针）

> 树的度数指的是一个结点的子结点个数。
> 
> 最大度数为5阶的含义为一个结点的子结点最多有五个

最上面的数据是（20,30,62,89），

*   *  小于20，走第一个指针
     *  20-30之间，走第二个指针
     *  30-62之间，走第三个指针
     *  62-89之间，走第四个指针
     *  89以上，走第五个指针

![image-20230523200106063][]

**下面进行演示： 依旧是五阶**

*  **首先插入四条数据（0023,0234,0345,0899）**

此时正好是四个Key，五个指针

![image-20230523200658644][]

*  **再插入1200数据**
    
    不能再往上面那个图添加了，如果添加之后变成了6阶，5个Key，6个指针了，所以**此时树会发生裂变—中间元素向上分裂**

如果1200插入进来后，0345会变成中间元素，会向上分裂

![image-20230523201647812][]

*  **再插入1234数据**

1234 > 0345，所以向右侧插入

![image-20230523201745027][]

*  **不断地插入数据**

![image-20230523201821555][]

*  **插入1000数据**

我们发现不能再继续往右下角插入了，已经慢了，所以仍然需要中间元素向上分裂，1000插入进来后，中间元素是1200，此时变成了

![image-20230523201948925][]

*  **不断插入**

![image-20230523202101139][]

*  **插入2456**

此时也不能向右下角插入，慢了，继续中间元素向上分裂，但是我们发现上面的元素也满了

![image-20230523202248916][]

#### 2.2.2 B+Tree ####

**B+Tree是B-Tree的变种，我们以一颗最大度数（max-degree）为5（5阶）的b+tree为例(4个Key，5个指针)**

*  在B+Tree当中，**所有的元素都会出现在叶子结点**

非叶子结点主要起到索引的作用，而叶子结点是用来存放数据的，最终在非叶子结点中形成了一个单项列表

![image-20230523202621111][]

**演示**

*  **插入数据（0232 ，0234，0567,1000）**

![image-20230523203611987][]

*  **再存储 890元素**

此时再插入后显然不是5阶，所以要中间元素向上分裂（0567）

与刚刚不一样的是，0567不仅向上还存在，向下也存在，并且形成了一个单项链表

**所有的元素出现在叶子结点**

![image-20230523203823029][]

*  **插入数据1234**

向右下角插入

![image-20230523204040750][]

*  **插入2345**

此时不能往右下角插入了，需要分裂

![image-20230523204129902][]

**在MySQL中的B+Tree索引是什么样子的呢？**

MySQL索引数据结构对经典的B+Tree进行了优化。

在原来B+Tree的基础上，增加一个指向相邻结点的链表指针，就形成了带有顺序指针的B+Tree，提高区间访问的性能

![image-20230523204847592][]

> 之前介绍过，叶在InnoDB当中默认是16K

#### 2.2.3 Hash结构 ####

**资料**：[ 数据结构——哈希表\_][Link 3]

**只有Memory存储引擎支持Hash结构，但是InnoDB引擎具有自适应Hash功能，Hash索引是存储引擎根据B+Tree在指定条件下自动构建的**

**哈希索引就是采用一定的hash算法，将键值换算成新的hash值，映射到对应的槽位上，然后存储在hash表中**

**比如**

首先算出每一条数据的Hash值，再通过数据库内部的哈希函数去计算每一个name的值，用这个值确定在落在哪一个哈希表的槽位上

如果两个(或多个)键值，映射到一个相同的槽位上，他们就产生了hash冲突（也称为hash碰撞），可以通过链表来解决。

![image-20230523205816072][]

**特点**

*  Hash索引只能用于对等比较(=，in)，不支持范围查询（between，>，< ，…）
 *  无法利用索引完成排序操作
 *  查询效率高，通常(不存在hash冲突的情况)只需要一次检索就可以了，效率通常要高于B+tree索引

#### 2.2.4 思考 ####

**为什么InnoDB存储引擎选择使用B+tree索引结构?**

*  **相对于二叉树，层级更少，搜索效率高**
 *  对于B-tree，无论是叶子节点还是非叶子节点，都会保存数据，这样导致一页中存储的键值减少，指针跟着减少，要同样保存大量数据，只能增加树的高度，导致性能降低；（**因为页的大小一定，存储的数据少了，那相应的存储指针的空间多了**）
 *  **相对Hash索引，B+tree支持范围匹配及排序操作**

### 2.3 索引分类 ###

<table> 
 <thead> 
  <tr> 
   <th>分类</th> 
   <th>含义</th> 
   <th>特点</th> 
   <th></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>主键索引</td> 
   <td>针对于表中主键创建的索引</td> 
   <td>默认自动创建，只能有一个</td> 
   <td>PRIMARY</td> 
  </tr> 
  <tr> 
   <td>唯一索引</td> 
   <td>避免同一个表中某数据列中的值重复</td> 
   <td>可以有多个</td> 
   <td>UNIQUE</td> 
  </tr> 
  <tr> 
   <td>常规索引</td> 
   <td>快速定位特定数据</td> 
   <td>可以有多个</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>全文索引</td> 
   <td>全文索引查找的是文本中的关键词，而不是比较索引中的值</td> 
   <td>可以有多个</td> 
   <td>FULLTEXT</td> 
  </tr> 
 </tbody> 
</table>

**在InnoDB存储引擎中，根据索引的存储形式，又可以分为以下两种**

<table> 
 <thead> 
  <tr> 
   <th>分类</th> 
   <th>含义</th> 
   <th>特点</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>聚集索引（Clustered Index）</td> 
   <td>将数据存储与索引放到一块，索引结构的叶子结点保存了行数据</td> 
   <td>必须有，有且只有一个</td> 
  </tr> 
  <tr> 
   <td>二级索引（Secondary Index）</td> 
   <td>将数据与索引分开存储，索引结构的叶子结点关联的是对应的主键</td> 
   <td>可以存在多个</td> 
  </tr> 
 </tbody> 
</table>

**聚集索引选取规则**：

*  如果**存在主键，主键索引就是聚集索引**
 *  如果**不存在主键，将使用第一个唯一（UNIQUE）索引作为聚集索引**
 *  如果没有主键，或没有合适的唯一索引，则**InnoDB会自动生成一个rowid作为隐藏的聚集索引**

如果二级索引下面也挂载的是整行的数据，那就和聚集索引冗余了，所以挂载的是数据的主键ID值

![image-20230524103451960][]

**select \* form user where name = ‘Arm’ 执行过程**

where name = ‘Arm’，所以根据name进行查询，选择二级索引。

Arm与Lee比较，发现Arm在Lee之前，所以向左下，就这么按照英文字母排序找，最终会找到ID值

拿到ID值（ID=10）之后再去聚集索引找完整数据数据，这个操作叫做**回表查询**

> 回表查询：先走二级索引拿到主键值，根据主键值再到聚集索引中找到行数据

> **思考**
> 
>     以下两条SQL语句，那个执行效率高? 为什么?
>     
>     A. select * from user where id = 10 ;
>     
>     B. select * from user where name = 'Arm' ;
>     
>     备注: id为主键，name字段创建的有索引；
> 
> **答**：A 语句的执行性能要高于B 语句。
> 
> 因为A语句直接走聚集索引，直接返回数据。 而B语句需要先查询name字段的二级索引，然后再查询聚集索引，也就是需要进行回表查询。

> **思考**
> 
>     **InnoDB主键索引的B+tree高度为多高呢?**
> 
> 页的大小为16K
> 
> InnoDB的指针占用6个字节的空间，
> 
> Key占用的空间取决于主键的类型，主键即使为bigint，占用字节数为8。
> 
> **假设**一行数据大小为1k，一页中可以存储16行这样的数据。
> 
> **高度为2时**
> 
> n表示当前结点Key的个数，8代表Key占用空间，（n+1）表示当前结点指针的个数，6代表指针占用的空间，16代表16K，16\*1024代表字节数
> 
> n \* 8 + (n + 1) \* 6 = 16\*1024 ,
> 
> 算出n约为 1170，即一个结点的Key个数为1170
> 
> 那指针的个数为1171，有多少个指针说明有多少页，每页又存储16K内容，每条数据假设1K，那就是存储16条数据
> 
> 即可存储 1171\* 16 = 18736 条数据
> 
>     **高度为3**：
> 
> 存储 1171 \* 1171 \* 16 = 21939856条数据（下图就是高度为3时的示意图）
> 
> 第一层会有1171个指针指向第二层，但是第二层的每个结点又有1171个指针指向第三层， 那一共有1171\*1171个指针也就是1171\*1171个页，每页存储16条数据，那就是 1171 \* 1171 \* 16 = 21939856条数据
> 
> ![image-20230524110340316][]

### 2.4.0 数据准备 ###

create table tb_user(
    
       id int primary key auto_increment comment '主键',
    
       name varchar(50) not null comment '用户名',
    
       phone varchar(11) not null comment '手机号',
    
       email varchar(100) comment '邮箱',
    
       profession varchar(11) comment '专业',
    
       age tinyint unsigned comment '年龄',
    
       gender char(1) comment '性别 , 1: 男, 2: 女',
    
       status char(1) comment '状态',
    
       createtime datetime comment '创建时间'
    
    ) comment '系统用户表';
    
    
    
    INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime)
    VALUES ('吕布', '17799990000', 'lvbu666@163.com', '软件工程', 23, '1','6', '2001-02-02 00:00:00');
    
    INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) 
    VALUES ('曹操', '17799990001', 'caocao666@qq.com', '通讯工程', 33,'1', '0', '2001-03-05 00:00:00');
    
    INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) 
    VALUES ('赵云', '17799990002', '17799990@139.com', '英语', 34, '1','2', '2002-03-02 00:00:00');
    
    INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) 
    VALUES ('孙悟空', '17799990003', '17799990@sina.com', '工程造价', 54,'1', '0', '2001-07-02 00:00:00');
    
    INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) 
    VALUES ('花木兰', '17799990004', '19980729@sina.com', '软件工程', 23,'2', '1', '2001-04-22 00:00:00');
    
    INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime)
    VALUES ('大乔', '17799990005', 'daqiao666@sina.com', '舞蹈', 22, '2','0', '2001-02-07 00:00:00');
    
    INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) 
    VALUES ('露娜', '17799990006', 'luna_love@sina.com', '应用数学', 24,'2', '0', '2001-02-08 00:00:00');
    
    INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) 
    VALUES ('程咬金', '17799990007', 'chengyaojin@163.com', '化工', 38,'1', '5', '2001-05-23 00:00:00');
    
    INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) 
    VALUES ('项羽', '17799990008', 'xiaoyu666@qq.com', '金属材料', 43,'1', '0', '2001-09-18 00:00:00');
    
    INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) 
    VALUES ('白起','17799990009', 'baiqi666@sina.com', '机械工程及其自动化', 27, '1', '2', '2001-08-16 00:00:00');
    
    INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) 
    VALUES ('韩信', '17799990010', 'hanxin520@163.com', '无机非金属材料工程', 27, '1', '0', '2001-06-12 00:00:00');
    
    INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) 
    VALUES ('荆轲', '17799990011', 'jingke123@163.com', '会计', 29, '1','0', '2001-05-11 00:00:00');
    
    INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) 
    VALUES ('兰陵王', '17799990012', 'lanlinwang666@126.com', '工程造价',44, '1', '1', '2001-04-09 00:00:00');
    
    INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) 
    VALUES ('狂铁', '17799990013', 'kuangtie@sina.com', '应用数学', 43,'1', '2', '2001-04-10 00:00:00');
    
    INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) 
    VALUES ('貂蝉', '17799990014', '84958948374@qq.com', '软件工程', 40,'2', '3', '2001-02-12 00:00:00');
    
    INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) 
    VALUES ('妲己', '17799990015', '2783238293@qq.com', '软件工程', 31,'2', '0', '2001-01-30 00:00:00');
    
    INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) 
    VALUES ('芈月', '17799990016', 'xiaomin2001@sina.com', '工业经济', 35,'2', '0', '2000-05-03 00:00:00');
    
    INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) 
    VALUES ('嬴政', '17799990017', '8839434342@qq.com', '化工', 38, '1','1', '2001-08-08 00:00:00');
    
    INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) 
    VALUES ('狄仁杰', '17799990018', 'jujiamlm8166@163.com', '国际贸易',30, '1', '0', '2007-03-12 00:00:00');
    
    INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) 
    VALUES ('安琪拉', '17799990019', 'jdodm1h@126.com', '城市规划', 51,'2', '0', '2001-08-15 00:00:00');
    
    INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) 
    VALUES ('典韦', '17799990020', 'ycaunanjian@163.com', '城市规划', 52,'1', '2', '2000-04-12 00:00:00');
    
    INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) 
    VALUES ('廉颇', '17799990021', 'lianpo321@126.com', '土木工程', 19,'1', '3', '2002-07-18 00:00:00');
    
    INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) 
    VALUES ('后羿', '17799990022', 'altycj2000@139.com', '城市园林', 20,'1', '0', '2002-03-10 00:00:00');
    
    INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) 
    VALUES ('姜子牙', '17799990023', '37483844@qq.com', '工程造价', 29,'1', '4', '2003-05-26 00:00:00');

### 2.4 索引语法 ###

*  **创建索引**

CREATE [ UNIQUE | FULLTEXT ] INDEX index_name ON table_name (index_col_name,... ) ;

如果建立的是一个常规索引， \[ UNIQUE | FULLTEXT \]内容可以省略

**index\_name 索引名称 一般是 inx\_表名\_字段名**

*  **查看索引**

SHOW INDEX FROM table_name ;

*  **删除索引**

DROP INDEX index_name ON table_name ;

**案例**

*  **name字段为姓名字段，该字段的值可能会重复，为该字段创建索引**

只能是创建一个常规索引，并且我们没有指定什么存储结构，那在InnoDB引擎中默认就是B+Tree存储结构

CREATE INDEX inx_user_name ON tb_user (name ) ;

创建完成后进行查看

show index from tb_user;

我们并没有手动创建主键索引，自动帮我们创建好了

![image-20230524171516926][]

*  **phone手机号字段的值，是非空，且唯一的，为该字段创建唯一索引**

create unique index idx_user_phone on tb_user(phone);

*  **为profession、age、status穿管联合索引**

创建联合索引**顺序有讲究**

create index idx_user_profession_age_status on tb_user(profession,age,status)

*  **为email建立合适的索引来提升查询效率**

创建一个常规索引即可

create index idx_user_email on tb_user(email)

### 2.5 SQL性能分析 ###

#### 2.5.1 SQL执行频率 ####

> 如果是以增删改为主，我们可以考虑不对其进行索引的优化。 如果是以查询为主，那么就要考虑对数据库的索引进行优化了。
> 
> 所以我们查看一些哪些SQL语句（增删改查）执行频率较高

**通过 show \[session|global\] status 命令可以提供服务器状态信息。**

*  session: 查看当前会话的信息
 *  global： 查询全局数据

**通过如下指令，可以查看当前数据库的INSERT、UPDATE、DELETE、SELECT的访问频次：**

七个下划线，匹配七个字符

SHOW GLOBAL STATUS LIKE 'Com_______';

![image-20230524173843064][]

#### 2.5.2 慢查询日志 ####

**慢查询日志记录了所有执行时间超过指定参数（long\_query\_time,单位：秒，默认10秒）的所有SQL语句的日志。**

> 假如我们知道了某个表是以查询为主，我们又该如何定位针对于那些查询语句进行优化呢？ 我们就可以借助慢查询日志定位哪些SQL执行效率比较低。

**Mysql的慢查询日志默认没有开启，需要在MySQL的配置文件（/etc/my.conf）中配置以下信息**

*  **查看是否开启慢查询日志**

show variables like 'slow_query_log'

![image-20230524174800052][]

*  **配置慢查询(Linux版本)**

# 开启MySQL慢日志查询开关
    slow_query_log=1
    # 设置慢日志的时间为2秒，SQL语句执行时间超过2秒，就会视为慢查询，记录慢查询日志
    long_query_time=2

配置完毕之后，通过以下指令重新启动MySQL服务器进行测试，查看慢日志文件中记录的信息/var/lib/mysql/localhost-slow.log。

systemctl restart mysqld

*  **配置慢查询 （Windows版本）**

找到my.ini文件夹，在mysqld处加入下面的代码

#开启慢查询
    slow_query_log = ON
    
    #log-slow-queries:代表MYSQL慢查询的日志存储目录,此目录文件一定要有写权限；
    log-slow-queries="C:/Program Files (x86)/MySQL/MySQL Server 5.0/log/mysql-slow.log"
    
    #最长执行时间 (查询的最长时间，超过了这个时间则记录到日志中) .
    long_query_time = 1
    
    #没有使用到索引的查询也将被记录在日志中
    log-queries-not-using-indexes = ON

![image-20230524175918820][]

然后可以查询日志

![image-20230524181359975][]

#### 2.5.3 profile 详情 ####

> 比如刚刚我们预设的时间是两秒，执行时间大于两秒的记录到慢查询日当中，小于两秒的不记录，假如一些耗时1.9秒的便不被记录在慢查询日志当中，不记录那就无法定位到SQL语句，为了定位这些SQL，我们便使用profile详情。

**show profiles能够在做SQL优化时帮助我们了解时间都耗费到哪里去了。**

**通过have\_profiling参数，能够看到当前MySQL是否支持profile操作**

SELECT @@have_profiling;

![image-20230524190740047][]

默认profiling是关闭的，可以通过set语句在session/global级别开启profiling

set [session | global] profiling =1;

**执行一系列的业务SQL的操作，然后通过如下指令查看指令的执行耗时：**

*  **查看每一条SQL耗时基本情况**

show profiles;

![image-20230524191721684][]

*  **查看指定query\_id的SQL语句个恩格尔阶段的耗时情况**

show profile for query query_id;

*  **查看指定query\_id的SQL语句的CPU使用情况**

show profile cpu for query query_id;

#### 2.5.4 explain 执行计划 ####

**Explain 或者 DESC命令获取MySQL如何执行Select语句的信息，包括在Select语句执行过程中表如何连接和连接的顺序。**

**语法**：

-- 直接在select语句之前加上关键字 explain / desc
    EXPLAIN SELECT 字段列表 FROM 表名 WHERE 条件 ;

![image-20230524194224623][]

<table> 
 <thead> 
  <tr> 
   <th>字段</th> 
   <th>含义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>id</td> 
   <td>select查询的序列号，表示查询中执行select子句或者是操作表的顺序(id相同，执行顺序从上到下；<strong>id不同，值越大，越先执行，如果id值相同，执行顺序从上到下</strong>)。</td> 
  </tr> 
  <tr> 
   <td>select_type</td> 
   <td>表示 SELECT 的类型，常见的取值有 SIMPLE（简单表，即不使用表连接或者子查询）、PRIMARY（主查询，即外层的查询）UNION（UNION 中的第二个或者后面的查询语句）、SUBQUERY（SELECT/WHERE之后包含了子查询）等</td> 
  </tr> 
  <tr> 
   <td>type</td> 
   <td>表示连接类型，性能由好到差的连接类型为NULL、system、const、eq_ref、ref、range、 index、all 。</td> 
  </tr> 
  <tr> 
   <td>possible_key</td> 
   <td>显示可能应用在这张表上的索引，一个或多个</td> 
  </tr> 
  <tr> 
   <td>key</td> 
   <td>实际使用的索引，如果为NULL，则没有使用索引</td> 
  </tr> 
  <tr> 
   <td>key_len</td> 
   <td>表示索引中使用的字节数， 该值为索引字段最大可能长度，并非实际使用长度，在不损失精确性的前提下， 长度越短越好 。</td> 
  </tr> 
  <tr> 
   <td>rows</td> 
   <td>MySQL认为必须要执行查询的行数，在innodb引擎的表中，是一个<strong>估计值，可能并不总是准确的</strong>。</td> 
  </tr> 
  <tr> 
   <td>filtered</td> 
   <td>表示返回结果的行数占需读取行数的百分比， filtered 的值越大越好。</td> 
  </tr> 
 </tbody> 
</table>

*  **多表查询时执行顺序问题**

下面的多表查询，观察ID，发现是内层查询先执行，subquery2代表第二个子查询

![image-20230524195233351][]

*  **有关type问题**

一般我们优化到const即可

**NULL**虽然是最好的，但是只有在**不查询任何表是才会出现**（业务查询时不太可能出现NULL级别）

![image-20230524200254305][]

**system在访问系统表的时候出现**

**const一般会出现在使用主键或者唯一索引访问时**

**ref一般会出现在使用非唯一性索引进行访问时**

**index表示使用了索引，但也会对索引进行扫描，遍历整个索引数**

**ALL代表全表扫描，性能会比较低**

### 2.6 使用规则 ###

#### 2.6.1 最左前缀法则 ####

**如果索引了多列（联合索引），要遵守最左前缀法则。**

*  **最左前缀法则指的是查询从索引最左列开始，并且不跳过索引中的列。**

> 如果跳跃了某一列，索引将部分失效（后面的字段索引失效）
> 
> 比如之前我们所添加的联合索引：
> 
>     create index idx_user_profession_age_status on tb_user(profession,age,status)
> 
> 根据上面的语句，最左变的列也就是profession必须存在，否则索引全部失效；如果查询时有profession字段，但是没有age字段，那查询status字段时索引会失效（部分失效）
> 
> **演示**
> 
> 下面的语句会走联合索引，因为最左边的列profession在查询条件中
> 
>     explain select * from tb_user where profession = '软件工程' and age = 31 and status = '0';
> 
> 下面的语句不会走联合索引，因为最左边的列不在查询条件中
> 
>     explain select * from tb_user where  age = 31 and status= '0';
> 
> 下面的语句会走联合索引,因为最左边的列存在，但是status不会走联合索引，虽然profession列存在，但是age列不存在，所以status查询时不能走联合索引
> 
>     explain select * from tb_user where profession = '软件工程'and status= '0';
> 
> 下面的语句会走联合索引，并且这三个字段都走了联合索引
> 
>     explain select * from tb_user where   status= '0'  and age = 31    and profession = '软件工程';

*  **范围查询**

联合索引中，出现范围查询（>,<），范围查询右侧的列索引失效

下面的语句中，status的索引失效，profession、age索引生效

explain select * from tb_user where profession = '软件工程' and age > 30 and status= '0';

这种情况再开发中**可以规避**，尽量使用大于等于或者小于等于

#### 2.6.2 索引失效情况 ####

*  **索引列运算**
    
    **不要在索引列进行运算操作，索引列将失效**
    
    如下所示

explain select * from tb_user where substring(phone,10,2) = '15';

*  **字符串不加引号**

**字符串类型字段使用时，不加引号，索引将失效**

如下所示，第二条索引失效

explain select * from tb_user where phone = '17799990015';
    explain select * from tb_user where phone = 17799990015;

*  **模糊查询**

如果仅仅是尾部模糊匹配，索引不会失效。**如果是头部模糊匹配，索引失效。**

在关键字后面加%，索引可以生效。而如果在关键字前面加了%，索引将会失效。

即语句二与语句三失效

explain select * from tb_user where profession like '软件%';
    explain select * from tb_user where profession like '%工程';
    explain select * from tb_user where profession like '%工%';

*  **or连接条件**
    
    **两侧都有索引时，索引才会生效**

用or分割开的条件， 如果or前的条件中的列有索引，而后面的列中没有索引，那么涉及的索引都不会被用到。

首先说明id存在主键索引，phone存在常规索引，age不存在索引

下面两条语句都不会走索引

explain select * from tb_user where id = 10 or age = 23;
    explain select * from tb_user where phone = '17799990017' or age = 23;

*  **数据分布影响**

**如果MySQL评估使用索引比全表更慢，则不使用索引**

因为索引是用来索引少量数据的，如果通过索引查询返回大批量的数据，则还不如走全表扫描来的快，此时索引就会失效。

**因此，is null 、is not null是否走索引，得具体情况具体分析，并不是固定的**

#### 2.6.3 SQL 提示 ####

执行SQL，创建profession的单列索引：

create index idx_user_pro on tb_user(profession);

并且之前我们也是用profession创建了一个联合索引，是最左侧的列,即现在profession有两个索引

那我们执行下面的语句，会使用哪个索引呢？ 选择了联合索引，这是MySQL自动选择的结果。

explain select * from tb_user where profession = '软件工程';

![image-20230524220907024][]

**SQL提示：是优化数据库的一个重要手段，简单来说，就是SQL语句中加入一些认为提示来达到优化操作的目的**

*  **use index**

建议MySQL使用哪一个索引完成此次查询（仅仅是建议，mysql内部还会再次进行评估）

explain select * from tb_user use index(idx_user_pro) where profession = '软件工程';

*  **ignore index**

忽略指定的索引。

explain select * from tb_user ignore index(idx_user_pro) where profession = '软件工程';

*  **force index**

强制使用索引。

explain select * from tb_user force index(idx_user_pro) where profession = '软件工程';

#### 2.6.4 覆盖索引 ####

**尽量使用覆盖索引（查询使用了索引，并且需要返回的列在索引中已经全部能够找到），减少 Select \*。**

> **为什么要减少Select \* 的使用？**
> 
>  *      占用更多的内存：SELECT * 会返回查询表中所有的列，这会占用更多的内存，对数据库的性能产生负面影响。如果只需要几列数据，那么最好只查询需要的数据，避免不必要的内存占用。
>  *  增加网络传输和数据传输的负载：当 SELECT \* 查询一张包含许多列的表时，网络传输的数据量也就更大，同时增加了传输时间对数据库请求的响应时间加长。
>  *  **不利于数据库索引的利用**：当查询中只需部分列时，我们可以通过索引迅速获取数据。但是，如果使用 SELECT \* 查询，则无法利用数据库索引准确地识别需要的数据。
>  *  代码不够明确易懂： SELECT \* 很难准确理解它返回的数据列，特别是当表有多个别名，而且在复杂查询语句中使用时，会使代码缺少明确性和可读性。

**下面语句不需要回表查询**：

profession,age,status三列有联合索引，属于二级索引，叶子结点挂载的就是id，所以我们直接在叶子结点中找到了id, profession,age,status四个字段，不需要回表查询

explain select id, profession,age,status
    from tb_user
    where profession = '软件工程' and age = 31 and status = '0' ;

**下面的语句需要回表查询**

explain select id,profession,age, status, name from tb_user where profession = '软
    件工程' and age = 31 and status = '0' ;

id,profession,age, status四个字段在二级索引的叶子结点中都有存储，但是name字段没有，需要去聚集索引中根据id进行查找（回表查询）。聚集索引的叶子结点挂载的是整行的数据

> using index condition：查找使用了索引，但是需要回表查询数据
> 
> using where；using index：查找使用了索引，但是需要的数据都在索引列中能找到，不需要回表查询数据

![image-20230525092805593][]

**案例**

一张表, 有四个字段(id, username, password, status), 由于数据量大, 需要对以下SQL语句进行优化, 该如何进行才是最优方案:

select id,username,password from tb_user where username = 'itcast';

**优化**：

create index idx_user_name_pass on tb_user(username,password);

#### 2.6.5 前缀索引 ####

当字段类型为字符串（varchar、text等）时，有时候需要索引很长的字符串，这会让索引变得很大，查询时，浪费大量的磁盘IO，影响查询效率。此时可以将字符串的一部分前缀，建立索引，这样可以大大节约索引空间，从而提高索引效率

*  **建立前缀索引**
    
    表示要使用前面的几个字符作为索引

create index idx_xxxx on table_name(column(n)) ;

**示例**

为email字段设置前缀索引，并且是利用前五个字符建立索引

create index idx_email_5 on tb_user(email(5));

**前缀长度**

可以根据索引的选择性来决定，而**选择性是指不重复的索引值（基数）和数据库表的记录总数的比值，索引选择性越高则查询效率越高。**

唯一索引的选择性是1，这是最好的选择性索引，性能也是最好的

**不重复的索引值（基数）和数据库表的记录总数的比值**

select count(distinct email) / count(*) from tb_user ;
    
    -- 从第一个字符开始截取，截取5个字符
    select count(distinct substring(email,1,5)) / count(*) from tb_user ;

*  **前缀索引的索引结构**

主键依然会构建一个聚集索引，在叶子结点存储整条数据。

利用email的前五个字符构建了一个前缀索引，因为前五个的区分度已经足够好了

**流程**

前面的流程相同不再叙述，直接从 从聚集索引中找到数据开始描述

最终在聚集索引中找到了整条数据row，然后拿到row的值中的email与’lvbu666@163.com‘进行比对，是否相等，因为刚刚只是比对了一个前缀，现在正式开始完整比较

![image-20230525103231789][]

#### 2.6.6 单列索引与联合索引 ####

**单列索引**：即一个索引只包含单个列

**联合索引**：即一个索引包含了多个列

**业务场景中，如果存在多个查询条件，考虑针对于查询字段建立索引时，建议建立联合索引，而非单例索引**

**判断下列语句会走phone索引还是name索引**（phone字段、name字段都存在单列索引）

explain select id, phone ,name from tb_user where phone = '17799990010' and name = '韩信'

使用了phone索引。

在and连接的两个字段 phone、name上都是有单列索引的，但是最终mysql只会选择一个索引，也就是说，只能走一个字段的索引，此时是会回表查询的。

![image-20230525105101091][]

为phone、name两个字段创建联合索引

create unique index idx_user_phone_name on tb_user(phone,name);

再执行查询语句

explain select id, phone ,name from tb_user where phone = '17799990010' and name = '韩信'

发现还是使用的phone的单列索引，这也是MySQL自动选择的结果

![image-20230525105548919][]

**刚刚创建的二级索引的示意图**

![image-20230525110654461][]

### 2.7 涉及原则 ###

*  针对于数据量较大，且查询比较频繁的表建立索引。
 *  针对于常作为查询条件（where）、排序（order by）、分组（group by）操作的字段建立索引。
 *  尽量选择区分度高的列作为索引，尽量建立唯一索引，区分度越高，使用索引的效率越高。
 *  如果是字符串类型的字段，字段的长度较长，可以针对于字段的特点，建立前缀索引
 *  尽量使用联合索引，减少单列索引，查询时，联合索引很多时候可以覆盖索引，节省存储空间，避免回表，提高查询效率。
 *  要控制索引的数量，索引并不是多多益善，索引越多，维护索引结构的代价也就越大，会影响增删改的效率
 *  如果索引列不能存储NULL值，请在创建表时使用NOT NULL约束它。当优化器知道每列是否包含NULL值时，它可以更好地确定哪个索引最有效地用于查询。

[image-20230523140643048]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/a2a2a810e89446fab166971814b2d814.png
[image-20230523143203137]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/e61b35d044834c73b1c0cdda87cb295c.png
[image-20230523144615344]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/4abbcb3c74ec4ce99190d59f7f61f6ea.png
[image-20230523144858938]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/929f4dfd437d4bf7aebd4b8c85a982dc.png
[image-20230523144946160]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/1b9c3a48e7b2489bb2b82565837316cc.png
[image-20230523150638909]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/9f5313bad06b4a949911633e71f2dd1e.png
[image-20230523164638566]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/929b8eb1f25346909bb47da9d30044cd.png
[Link 1]: https://blog.csdn.net/weixin_51351637/article/details/129941022
[image-20230523183533929]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/75595d58a026475da6daf1e38a7dac46.png
[Link 2]: https://blog.csdn.net/weixin_51351637/article/details/129422343
[image-20230523195036558]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/ada99b2c900e4ca186e7425bd785b00f.png
[image-20230523200106063]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/9966217e30ae4ad3bb5b3f5628008d1a.png
[image-20230523200658644]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/42225acdb2874d37a72b2a92bf6d9e50.png
[image-20230523201647812]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/f2d25a2282b74571b9dc7660a9bfea4a.png
[image-20230523201745027]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/0f4f5ae66746471aa65cf55d9d214c7c.png
[image-20230523201821555]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/a49317f0b2cb4f138ccba490a9fbb137.png
[image-20230523201948925]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/78455ac4bdbe4f258c0c120e7715ebc5.png
[image-20230523202101139]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/636377e24c5e409e907fe34869527307.png
[image-20230523202248916]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/bbf396d6e7a04798b28dd2f4905c804d.png
[image-20230523202621111]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/9441df17fa97441eb48a0381ca335864.png
[image-20230523203611987]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/f56b2b2adf0143d0a1b01848f5328d9d.png
[image-20230523203823029]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/cc5367df9595411e98e1f798c082c441.png
[image-20230523204040750]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/e14e0798deeb4bfbac9582b5db0c6867.png
[image-20230523204129902]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/e85d48031429417c89d6f120fefd7244.png
[image-20230523204847592]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/cbd161790a5642b4bbe5f216a2768907.png
[Link 3]: https://blog.csdn.net/weixin_51351637/article/details/129417607?ydreferer=aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl81MTM1MTYzNy9jYXRlZ29yeV8xMjE0MTE4NS5odG1sP3NwbT0xMDAxLjIwMTQuMzAwMS41NDgy
[image-20230523205816072]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/99e29ca46eae4153b34957ce05527321.png
[image-20230524103451960]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/eb6d89ad40e9402d87ac46f4fbd47ec0.png
[image-20230524110340316]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/b98b1ee30b7c433c81bd6d121cf131a5.png
[image-20230524171516926]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/9e9267fa50ba418aa632b70370b7dcb4.png
[image-20230524173843064]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/9c5815edf8bb48aba7861115854bba3a.png
[image-20230524174800052]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/facff7cd82b34242898e11e910be545a.png
[image-20230524175918820]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/3dbb5c79f43545a7bdf11c87edcd4e73.png
[image-20230524181359975]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/fdf9f484990f42d48e06c996a4bdba45.png
[image-20230524190740047]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/d7e85b9505054122afe35a0a4dfb971c.png
[image-20230524191721684]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/71a64cf73a5441829d72b7030a1854fd.png
[image-20230524194224623]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/5afed9b02341457fbbf2e9545bc52e1c.png
[image-20230524195233351]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/01d2f33a4f07408285e99f074d6be431.png
[image-20230524200254305]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/c2d2d74574594b62a8e185adc0623fd7.png
[image-20230524220907024]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/a7b616e4b453449590efeacb329f3f4d.png
[image-20230525092805593]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/ca9f8a23a994462badb710269676ff63.png
[image-20230525103231789]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/afd042a709c74406a31331e4fc0a4a2d.png
[image-20230525105101091]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/d77a8d7e85e24cdbae5a819f397ff153.png
[image-20230525105548919]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/117821dc50a24ef795adf99504279178.png
[image-20230525110654461]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/c1d877f767b3438bb74f93febcbe7194.png