使我日渐消瘦的MySQL索引

淡淡的烟草味﹌ 2023-02-10 12:28 60阅读 0赞

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70][]

若不是生活所迫，我怎会把自己弄得一身才华。

[数据结构索引之杀死攻略（一）][Link 1]

[mysql 索引][mysql]

# 0 那些年我们听过的索引优化手段 #

>  *  不用 select \*，写明具体查询字段
>  *  避免在 where 索引字段中使用 != 或 <> 操作符
>  *  模糊匹配 like \_%，like %\_%，like %\_ 可能用不到索引
>  *  索引并非越多越好
>  *  ......

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 1][]

为了成为一只知其然知其所以然的闲狗，我开始了下面的探索之路。

# 1 索引可以大幅提升查询效率？ #

先来个小测试，我先挖来一张有 100 0000 条记录的用户表 user

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 2][]

这张表目前只在 id 上有一个主键索引，其他字段都没有索引。下面在一个没有索引的字段 account\_name 做一个查询操作

![2020060623333190.png][]

给这个字段创建一个普通索引，耗时 1.960000s

ALTER TABLE t_user ADD INDEX idx_nick_name(nick_name);

然后再执行相同的查询操作，神速啊 !

![20200606233624739.png][]

# 2 索引到底是个啥呢？ #

**索引（indexing）：**是一种数据结构，是把一个个关键码与它对应的数据记录位置相关联的过程，用来协助快速查询，更新数据库表中数据。

> 数据结构：计算机存储，组织数据的一种方式。直白地理解,就是研究数据的逻辑结构和存储结构。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 3][]

> 索引相当于书籍的目录，为了方便查找书中的内容，针对内容建立索引形成了目录。

既然索引是一种数据结构，那它也会以一定的方式来存储自己的数据，并且存储在磁盘上。

> 好比书籍的目录也占用了纸张。

查看表的对象信息，会发现索引也占用大量的存储空间，所以不适合放在内存。

![20200607091905423.png][]

![20200525075402786.png][]

原来没有索引的时候，检索数据时需要遍历整张表的数据，根据每条数据在磁盘存储的顺序，一行一行去对比。

自从有了索引，一切都不一样了。如果在 id 字段建立了索引，id字段的值会被加到索引里，其他字段同理。然后检索的时候，只需要根据 id 的值去检索索引，得到数据的磁盘地址，根据磁盘地址就可以快速地获取到数据。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 4][]

# 3 索引类型 #

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 5][]

（1）按索引存储结构划分： B Tree  索引、 Hash  索引、 FULLTEXT  全文索引、 R Tree  索引

（2）按应用层次划分：普通索引、唯一索引、主键索引、复合索引

（3）按索引键值类型划分：主键索引、辅助索引（二级索引）

（4）按数据存储和索引键值逻辑关系划分：聚集索引（聚簇索引）、非聚集索引（非聚簇索引）

## 3.1 Normal 普通索引 ##

基本的索引类型，没有唯一性的限制，允许为 NULL 值。

## 3.2 Unique 唯一索引 ##

索引字段的值必须唯一，但允许有一个 NULL 值。

验证：login\_name 为唯一索引，设置两个 NIULL 值会报错。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 6][]

缺点：唯一索引在插入之前要先遍历一遍数据，保证没有重复，所以会导致插入速度变慢。

## 3.3 主键索引 ##

它是一种特殊的唯一索引，不允许有空值，每个表只能有一个主键。

## 3.4 复合索引 ##

复合索引指在多个列上建立索引，复合索引可以替代多个单一索引，相比多个单一索引，复合索引开销更小。

索引同时有两个概念叫做窄索引和宽索引，窄索引是指索引列为1-2列的索引，宽索引也就是索引列超过2列的索引，能用窄索引就不用宽索引，因为窄索引往往比组合索引更有效。

**复合索引使用注意事项：**

如果表已经建立了 (col1 ， col2) ，就没有必要再单独建立（ col1 ）；如果现在有 (col1) 索引，如果查询需要col1 和 col2 条件，可以建立 (col1,col2) 复合索引，对于查询有一定提高。

## 3.5 Full text 全文索引 ##

查询操作在数据量比较少时，可以使用 like 模糊查询，但是对于大量的文本数据检索，效率很低。如果使用全文索引，查询速度会比 like  快很多倍。在  MySQL 5.6  以前的版本，只有  MyISAM 存储引擎支持全文索引，从 MySQL 5.6  开始  MyISAM  和  InnoDB  存储引擎均支持。 和常用的 like  模糊查询不同，全文索引有自己的语法格式，使用  match  和  against  关键字，比如

select * from user where match(name) against('aaa');

**全文索引使用注意事项：**

（1）全文索引必须在字符串、文本字段上建立；

（2）全文索引字段值必须在最小字符和最大字符之间的才会有效；（ innodb ： 3-84 ； myisam ： 4- 84）

（3）全文索引字段值要进行切词处理，按  syntax  字符进行切割，例如  b+aaa ，切分成  b  和  aaa 全文索引匹配查询，默认使用的是等值匹配，例如 a  匹配  a ，不会匹配  ab,ac 。如果想匹配可以在布尔模式下搜索 a\*

select * from user where match(name) against('a*' in boolean mode);

# 4 MySQL 索引方法（逻辑结构） #

## ![20200526075125612.png][] ##

## 4.1 Hash 结构 ##

[散列表的检索][Link 2]

Hash 底层通过 Hash 表来实现，通过 <key, value> 存储数据，适用于根据 key 查找 value，但不适用于范围查询，范围查询需要全表扫描。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 7][]

**InnoDB 自适应哈希索引**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 8][]

InnoDB  存储引擎会监控表上各个索引页的查询，当 InnoDB 注意到某些索引值访问非常频繁时，会在内存中基于 B+Tree 索引再创建一个哈希索引， 快速定位访问频繁的索引页。

InnoDB  自适应哈希索引采用的等值查询效率要优于 B+Tree，B+Tree 查询的时间复杂度受树高影响。

show engine innodb status; 
    show variables like '%innodb_adaptive%';
    #关闭
    set global innodb_adaptive_hash_index=0;

## 4.2 BTREE 结构 ##

> 猜数字游戏：给定一个1～100的自然数，给你5次机会，你能猜中这个数字吗？你会从多少开始猜？
> 
> [二分查找][Link 3]

上面猜数字的方法可以利用到二分查找思想，而二分查找通常采用二叉树作为逻辑结构，采用顺序存储结构存储在磁盘。

### 4.2.1 二叉搜索树（Binary Search Tree） ###

[二叉搜索树][Link 4]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 9][]

BST的**中序遍历序列**，必然单调非降。

> 查找的效率决定于树的高度，若树的高度是h，那么查找过程的时间复杂度就是O(h)，等同于二分查找。

极端情况下，时间复杂度会退化到O(n)。如：顺序插入。 [BST演示][BST]

### ![20200528082454642.png][] ###

采用这样的数据结构作为索引的逻辑结构就太恐怖了，pass！

![20200528082845692.png][]

### 4.2.2 平衡二叉树（AVL Tree - Balance Binary Search Tree） ###

[AVL（平衡二叉搜索）树学习笔记][AVL]

[AVL 演示][AVL 1]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 10][]

特点：左右子树深度差的绝对值不能超过 1。主要通过旋转来维持平衡。

**灵魂拷问：用 AVL 作为索引存储数据的逻辑结构可行吗？**

![20200529080120238.png][]

先瞅一眼 AVL 的数据存储

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 11][]

每一个节点占用一个磁盘块，存放键值，完整数据所在磁盘块的磁盘地址，子节点的引用。

查找 id = 23 的过程

>  *  把 id = 26 的结点从磁盘加载到内存，对比键值，26 > 23
>  *  把 id = 19 的结点从磁盘加载到内存，对比键值，19 < 23
>  *  把 id = 23 的结点从磁盘加载到内存，对比键值，23 == 23，匹配，通过结点存储的完整数据的磁盘地址，读取对应的数据。

InnoDB 操作磁盘的最小单位是 Page，默认为 16KB（16\*1024=16384 B）。即进行一次 I/O 会把 16 KB 的数据从磁盘加载到内存。即每个二叉树结点占用的磁盘大小为 16 KB。16 KB 的结点只存一个键值是不是太浪费了！！！如上图，才 6 条数，查找 id = 23 时就进行了 3 次 I/O 操作。

怎么解决好呢？

难得去一趟磁盘，是不是得多取点数据，即每个结点多存点数据。然后，诞生了 B 树。

![20200601080114194.png][]

### 4.2.3 多路平衡查找树（Balanced Tree B Tree） ###

[B树学习笔记之B树的查找][B_B]

[动态索引之B树][B]

（1）索引值和  data  数据分布在整棵树结构中

（2）每个节点可以存放多个索引值及对应的 data 数据

（3）树节点中的多个索引值从左到右升序排列

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 12][]

[B树演示][B 1]

### 4.2.4 加强版多路平衡查找树（B+ Tree） ###

[动态索引之B+树][B 2]

B+ 树是 B 树的升级版

（1）非叶子节点不存储数据，只存储索引值，这样便于存储更多的索引值

> 假设 1 条记录 1 KB 大小，一个结点 16KB（16\*1024=16384 B）
> 
> ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 13][]
> 
> 树高为 3 的 B+ 树，即可以存放 2190 2400条记录。

（2）叶子节点包含了所有的索引值和数据

（3）叶子节点用指针连接，提高区间的访问性能

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 14][]

相比 B 树，B+ 树进行范围查找时，只需要查找定位两个节点的索引值，然后利用叶子节点的指针进行遍历即可，不用回到根结点。而 B 树需要遍历范围内所有的节点和数据，显然 B+Tree 效率更高。

**例子：**

# 5 存储引擎的索引实现 #

## 5.1 基本概念 ##

[官方文档][Link 5]

存储引擎（表类型，表处理器）：负责 MySQL 中数据的存储和提取。由于数据的存储方式，存储格式和使用方式不同，就会对应产生不同的存储引擎。5.5 版本后默认每张表的存储引擎为 InnoDB。

> （1）数据存储方式：有的数据比较稳定，然后存在磁盘；有的数据经常要被访问，需要放在内存。
> 
> （2）数据存储格式：经常访问的数据，用 B+ 树的结构去存储；不常访问的数据进行压缩处理，节省空间；有的数据想要看起来比较直观，便于不同系统的交互，就采用 csv 的格式去存储。
> 
> （3）数据使用方式不同：有的数据需要有较高的一致性，就需要存储引擎支持事务；有的不需要事务，但需要更高的访问速度，这就需要存储引擎支持 B+ 树。

下面探索一下数据在磁盘以什么样的形式体现

*  创建两张除了存储引擎不同，其它字段都相同的两张表

CREATE TABLE `user_innodb` (
      `Id` int NOT NULL AUTO_INCREMENT,
      `user_id` bigint DEFAULT NULL COMMENT '用户Id',
      `account_name` varchar(32) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
      `email` varchar(64) DEFAULT NULL,
      `phone_num` varchar(16) DEFAULT NULL,
      `password` varchar(40) DEFAULT NULL,
      `nick_name` varchar(32) DEFAULT NULL COMMENT '昵称',
      PRIMARY KEY (`Id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
    
    CREATE TABLE `user_myisam` (
      `Id` int NOT NULL AUTO_INCREMENT,
      `user_id` bigint DEFAULT NULL COMMENT '用户Id',
      `account_name` varchar(32) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
      `email` varchar(64) DEFAULT NULL,
      `phone_num` varchar(16) DEFAULT NULL,
      `password` varchar(40) DEFAULT NULL,
      `nick_name` varchar(32) DEFAULT NULL COMMENT '昵称',
      PRIMARY KEY (`Id`)
    ) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

查看 mysql 数据文件存放目录

SHOW VARIABLES LIKE 'datadir';

![20200607232316547.png][]

进入相应的目录，找到以数据库名命名的目录，我的是 test

## ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 15][] ##

然后发现，每张表都是以文件的形式存在磁盘。innodb的表有一个文件，而myisam的表有两个文件。

> MySQL 8.0 以前，每张表都有一个 frm 文件，用来存放表的元数据（meta），包括表结构的定义等。MySQL 8.0 以后，元数据都存在系统表空间里。

## 5.2 常用的存储引擎 ##

[关系型数据库的 B-Tree 索引][B-Tree]

### 5.2.1 MyISAM ###

MyISAM 数据表的索引文件和数据文件是分开存储的，MyISAM 的主键索引与辅助索引没有区别，都存在 .MYI 文件里。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 16][]

### 5.2.2 InnoDB ###

**（1）主键索引**

**[聚集索引文档][Link 6]**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 17][]

> 完整数据存放在叶子结点，数据与索引在同一棵树，同一个文件里。完整数据的物理存放顺序与主键一致，这样的索引也称为聚簇索引。聚簇索引决定了数据物理存放顺序。如果一张表没有主键索引，InnoDB 内部会优先去查找没有空值的唯一索引，如果也没有InnoDB 内部会为每一行数据都生成一个 rowID，rowID 构建的索引作为聚簇索引，决定数据的物理顺序。
> 
> If the table has no `PRIMARY KEY` or suitable `UNIQUE` index, `InnoDB` internally generates a hidden clustered index named `GEN_CLUST_INDEX` on a synthetic column containing row ID values. The rows are ordered by the ID that `InnoDB` assigns to the rows in such a table. The row ID is a 6-byte field that increases monotonically as new rows are inserted. Thus, the rows ordered by the row ID are physically in insertion orde.

查询下 rowid，是真的有诶！

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 18][]

**（2）辅助索引（二级索引）**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 19][]

> 完整数据只会存放在主键索引的叶子结点，辅助索引的叶子结点存放对应的字段值和主键值。
> 
> InnoDB 的辅助索引会比主键索引多扫描一棵 B+ 树

# 6 索引分析与优化 #

## 6.1 EXPLAIN ##

MySQL  提供了一个  EXPLAIN  命令，用来对  SELECT  语句进行分析，并输出  SELECT  执行的详细信息，供开发人员有针对性的优化。

CREATE TABLE `t_resume` (
      `id` bigint NOT NULL AUTO_INCREMENT,
      `address` varchar(255) DEFAULT NULL,
      `name` varchar(255) DEFAULT NULL,
      `phone` varchar(255) DEFAULT NULL,
      PRIMARY KEY (`id`),
      KEY `index_address` (`address`)
    ) ENGINE=InnoDB AUTO_INCREMENT=10 DEFAULT CHARSET=utf8;
    
    EXPLAIN SELECT * from t_resume WHERE address = "3";

![20210410125241254.png][]

**select\_type**

>  *  SIMPLE ： 表示查询语句不包含子查询或 union 
>  *  PRIMARY：表示此查询是最外层的查询 
>  *  UNION：表示此查询是UNION的第二个或后续的查询
>  *  DEPENDENT UNION：UNION中的第二个或后续的查询语句，使用了外面查询结果 
>  *  UNION RESULT：UNION的结果 
>  *  SUBQUERY：SELECT子查询语句 
>  *  DEPENDENT SUBQUERY：SELECT子查询语句依赖外层查询的结果

**type**

>  *  ALL：表示全表扫描，性能最差
>  *  index：表示基于索引的全表扫描，先扫描索引再扫描全表数据
>  *  range：表示使用索引范围查询。使用>、>=、<、<=、in等等
>  *  ref：表示使用非唯一索引进行单值查询
>  *  eq\_ref：一般情况下出现在多表join查询，表示前面表的每一个记录，都只能匹配后面表的一行结果
>  *  const：表示使用主键或唯一索引做等值查询，常量查询
>  *  NULL：表示不用访问表，速度最快

**possible\_keys**

> 表示查询时可能能够使用到的索引

**key**

> 表示查询时真正使用到的索引

**key\_len**

> 表示查询使用了索引的字节数量，可以判断是否全部使用了组合索引。

**rows**

> 字符串类型 
> 
>  *  字符串长度跟字符集有关：latin1=1、gbk=2、utf8=3、utf8mb4=4 
>  *  char(n)：n\*字符集长度 
>  *  varchar(n)：n \* 字符集长度 \+ 2字节 
> 
> 数值类型 
> 
>  *  TINYINT：1个字节 
>  *  SMALLINT：2个字节 
>  *  MEDIUMINT：3个字节 
>  *  INT、FLOAT：4个字节 
>  *  BIGINT、DOUBLE：8个字节 
> 
> 时间类型 
> 
>  *  DATE：3个字节 
>  *  TIMESTAMP：4个字节 
>  *  DATETIME：8个字节 
> 
> 字段属性 
> 
>  *  NULL属性占用1个字节，如果一个字段设置了NOT NULL，则没有此项

**Extra**

>  *  Using where 表示查询需要通过索引回表查询数据
>  *  Using index 表示查询需要通过索引，索引就可以满足所需数据
>  *  Using fifilesort 表示查询出来的结果需要额外排序，数据量小在内存，大的话在磁盘，因此有Using fifilesort 建议优化
>  *  Using temprorary 查询使用到了临时表，一般出现于去重、分组等操作

## 6.2 列的离散度 ##

离散度公式：count(distinct(column\_name)):count(\*) 某列不重复值的个数/总数。

**实战一下**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 20][]

gender 的离散度要小于 phone

**（1）在 gender 字段创建索引**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 21][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 22][]

将近扫描了一半的数据。

检索数据时，因为重复值多，所以扫描的行数也多。如果在 B+Tree 里面的重复值太多，MySQL 的优化器发现走索引跟使用全表扫描差不多的时候，就算建了索引，也不一定会走索引。

**（2）在 phone 字段创建索引**

![2021041017483980.png][]

只需扫描一行。

**闲狗言：**

> 优先选择离散度高的字段建立索引

## 6.3 **回表与覆盖索引** ##

**回表：**InnoDB 的完整数据都在存放在主键索引的叶子节点的，查询主键以外的字段时，需要先查询辅助索引，然后再查询主键索引获取完整数据，比直接查询主键索引多扫描了一棵 B+ 树，这个过程称为回表。也就是查完了辅助索引还要查主键索引。

**覆盖索引：**select 的列包含在所用到的索引里，即可以在一棵索引数上就能获取 SQL 所需的所有列数据，无需回表，速度更快。

**实现索引覆盖最常见的方法**：将被查询的字段，建立到组合索引。

**实战一下**

**（1）** 创建 name 和 phone 的组合索引

ALTER TABLE t_user ADD INDEX idx_name_phone(name,phone);

当 select name,phone 时，不需要主键索引里的完整数据，直接查 name 和 phone 的辅助索引就可以获取到 name 和 phone 的值，不用回表。

> 当 extra 出现 Using index 则表示用到了覆盖索引

**（2）**

explain select * from t_user where name="tanjinhai";

![20200614212316931.png][]

**（3）**

explain select name,phone from t_user where name="屿昔" and phone="15505688900";

![20200614213041240.png][]

这是典型的用到了覆盖索引的情况

explain select phone from t_user where name="屿昔";

**（4）**

explain select phone from t_user where phone="17665453887";

![20200614213917681.png][]

要查的 phone 虽然在辅助索引里，但是违背了联合索引最左匹配原则。MySQL 优化器判断了下回表的代价和直接在辅助索引中过滤数据的代价，还是选择了不回表。

**闲狗言：**

> 避免使用 select \*，用到什么字段就查询什么字段

## **6.4** 联合索引最左匹配 ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 23][]

复合索引使用时遵循最左前缀原则，即查询时从最左边的列开始查，就会使用到索引，如果从索引的第二列开始查找，索引将失效。

**实战一下**

**（1）**创建组合索引 name 和 phone

ALTER TABLE t_user ADD INDEX idx_name_phone(name,phone);

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 24][]

**（2）**

explain select * from t_user where name="tanjinhai" and phone="15920690159";

![20200614200726115.png][]

**（3）**

explain select * from t_user where phone="15920690159" and name="tanjinhai";

**![20200614201321887.png][]**

居然还能用到索引，这不是违背了联合索引最左匹配原则吗？我跟你港，其实 MySQL 内部有一个查询优化器 Optimizer， 它会自动帮我们调整下查询条件的顺序。

**（4）**

explain select * from t_user where name="tanjinhai";

![20200614202806132.png][]

**（5）**

explain select * from t_user where phone="15920690159";

![20200614202905582.png][]

**闲狗言：**

> （1）使用索引的顺序要跟建立索引的顺序一致
> 
> （2）建立组合索引时要把最常用的字段放在左边

## 6.5 LIKE 查询 ##

**（1）索引失效**

EXPLAIN SELECT * from t_resume WHERE phone like "%176%";

![20210410194850338.png][]

**（2）索引失效**

EXPLAIN SELECT * from t_resume WHERE phone like "%176";

![20210410194901838.png][]

**（3）索引有效**

EXPLAIN SELECT * from t_resume WHERE phone like "176%";

![20210410194954243.png][]

## 6.6 NULL 查询 ##

对 MySQL 来说， NULL 是一个特殊的值，从概念上讲， NULL  意味着 “ 一个未知值 ” ，它的处理方式与其他值有些不同。比如：不能使用 = ， < ， >  这样的运算符，对  NULL  做算术运算的结果都是  NULL ， count  时不会包括 NULL  行等，而且  NULL  是占用存储空间的。

select length(NULL), length(''), Length(' ');

![2021041020081759.png][]

>  *  空值 (NULL) 的长度是 NULL，不确定占用了多少存储空间，但是占用了存储空间
>  *  空字符串 ('') 的长度是 0，不占用存储空间
>  *  含一个空格的字符串 (' ') 长度为 1，占用了存储空间

**灵魂拷问：如果MySQL表的某一列含有NULL值，那么包含该列的索引是否有效？**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 25][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 26][]

真相就是可以使用到索引。

**闲狗言：**

> 指定列为 NOT NULL，除非你想存储 NULL。在 MySQL 中，含有空值的列很难进行查询优化，因为它们使得索引、索引的统计信息以及比较运算更加复杂。应该使用-1，0 等特殊值去替代空值，如果是datetime类型，也可以设置系统当前时间或某个固定的特殊值，例如 '1970-01-01 00:00:00'。
> 
> If an indexed column cannot contain any `NULL` values, declare it as `NOT NULL` when you create the table. The optimizer can better determine which index is most effective to use for a query, when it knows whether each column contains `NULL` values.
> 
> [官网文档][Link 7]

## 6.7 索引与排序 ##

MySQL  查询支持  fifilesort  和  index  两种方式的排序， fifilesort  是先把结果查出，然后在缓存或磁盘进行排序操作，效率较低。 index  是指利用索引自动实现排序，不需另做排序操作，效率会比较高。

**fifilesort 排序算法：** 双路排序和单路排序。

> 双路排序：需要两次磁盘扫描读取，最终得到用户数据。第一次将排序字段读取出来，然后排序；第二次去读取其他字段数据。 
> 
> 单路排序：从磁盘查询所需的所有列数据，然后在内存排序将结果返回。如果查询数据超出缓存 sort\_buffffer，会导致多次磁盘读取操作，并创建临时表，最后产生多次  IO ，导致负担增加。

**解决方案：**

>  *  少使用select \*
>  *  增加 sort\_buffffer\_size 容量和 max\_length\_for\_sort\_data 容量

如果我们  Explain  分析  SQL ，结果中  Extra  属性显示  Using fifilesort ，表示使用了  fifilesort  排序方式，需要优化。如果 Extra  属性显示  Using index  时，表示覆盖索引，也表示所有操作在索引上完成，也可以使用 index 排序方式，建议尽可能采用覆盖索引，为排序的字段建立索引。

**实战一下：**

**（1）**

EXPLAIN SELECT id from t_user where age=22 ORDER BY `name`;

创建 age 和 name 的组合索引

![20210411121210298.png][]

**（2）**

EXPLAIN SELECT id from t_user where name = 'kk' ORDER BY name;

创建 name 索引

![2021041112240957.png][]

## 6.8 索引并非越多越好 ##

>  *  大部分情况下，索引能大幅度提高查询效率，但是数据的变更（增删改）都需要维护索引，更多的索引意味着更多的维护成本，更多的索引也意味着需要更多的空间。好比，一本 100 页的书，却有 50 页目录？
>  *  过小的表，建立索引后查询效率可能更低。好比，读个 2 页的宣传手册，你还要先去查目录？![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 27][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200520220925507.jpeg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[Link 1]: https://blog.csdn.net/wydyd110/article/details/81904483
[mysql]: https://ke.qq.com/course/1910186?taid=8028668267668906
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200527003751652.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200606232140638.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[2020060623333190.png]: https://img-blog.csdnimg.cn/2020060623333190.png
[20200606233624739.png]: https://img-blog.csdnimg.cn/20200606233624739.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20200606234929693.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[20200607091905423.png]: https://img-blog.csdnimg.cn/20200607091905423.png
[20200525075402786.png]: https://img-blog.csdnimg.cn/20200525075402786.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20200525082922972.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/20200526075059222.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 6]: https://img-blog.csdnimg.cn/20200717131001621.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[20200526075125612.png]: https://img-blog.csdnimg.cn/20200526075125612.png
[Link 2]: https://blog.csdn.net/wydyd110/article/details/82144549#4%C2%A0%20%E6%95%A3%E5%88%97%E8%A1%A8%E7%9A%84%E6%A3%80%E7%B4%A2
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 7]: https://img-blog.csdnimg.cn/20210409175700705.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 8]: https://img-blog.csdnimg.cn/20210409185539415.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[Link 3]: https://blog.csdn.net/wydyd110/article/details/82113893#2.2%20%E4%BA%8C%E5%88%86%E6%A3%80%E7%B4%A2
[Link 4]: https://blog.csdn.net/wydyd110/article/details/82994739#4%20%E4%BA%8C%E5%8F%89%E6%90%9C%E7%B4%A2%E6%A0%91%EF%BC%88Binary%20Search%20Tree%EF%BC%89
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 9]: https://img-blog.csdnimg.cn/20200709230629745.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[BST]: https://www.cs.usfca.edu/~galles/visualization/BST.html
[20200528082454642.png]: https://img-blog.csdnimg.cn/20200528082454642.png
[20200528082845692.png]: https://img-blog.csdnimg.cn/20200528082845692.png
[AVL]: https://blog.csdn.net/wydyd110/article/details/79413097
[AVL 1]: https://www.cs.usfca.edu/~galles/visualization/AVLtree.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 10]: https://img-blog.csdnimg.cn/20200529075303870.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[20200529080120238.png]: https://img-blog.csdnimg.cn/20200529080120238.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 11]: https://img-blog.csdnimg.cn/2020052908023292.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[20200601080114194.png]: https://img-blog.csdnimg.cn/20200601080114194.png
[B_B]: https://blog.csdn.net/wydyd110/article/details/80097181
[B]: https://blog.csdn.net/wydyd110/article/details/81945803#3.1%C2%A0%20B%E6%A0%91%EF%BC%88B-%E6%A0%91%EF%BC%89
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 12]: https://img-blog.csdnimg.cn/20200601080328976.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[B 1]: https://www.cs.usfca.edu/~galles/visualization/BTree.html
[B 2]: https://blog.csdn.net/wydyd110/article/details/81945803#3.2%C2%A0%20B%2B%E6%A0%91
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 13]: https://img-blog.csdnimg.cn/20200708234301436.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 14]: https://img-blog.csdnimg.cn/20200601081446296.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[Link 5]: https://dev.mysql.com/doc/refman/8.0/en/innodb-storage-engine.html
[20200607232316547.png]: https://img-blog.csdnimg.cn/20200607232316547.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 15]: https://img-blog.csdnimg.cn/20200607232919676.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[B-Tree]: https://blog.csdn.net/wydyd110/article/details/105670950
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 16]: https://img-blog.csdnimg.cn/20210409224836927.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[Link 6]: https://dev.mysql.com/doc/refman/8.0/en/innodb-index-types.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 17]: https://img-blog.csdnimg.cn/20200608000522738.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 18]: https://img-blog.csdnimg.cn/20200608003041113.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 19]: https://img-blog.csdnimg.cn/20200710000939215.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[20210410125241254.png]: https://img-blog.csdnimg.cn/20210410125241254.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 20]: https://img-blog.csdnimg.cn/20210410174244418.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 21]: https://img-blog.csdnimg.cn/20210410173817510.jpeg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 22]: https://img-blog.csdnimg.cn/20210410174536334.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[2021041017483980.png]: https://img-blog.csdnimg.cn/2021041017483980.png
[20200614212316931.png]: https://img-blog.csdnimg.cn/20200614212316931.png
[20200614213041240.png]: https://img-blog.csdnimg.cn/20200614213041240.png
[20200614213917681.png]: https://img-blog.csdnimg.cn/20200614213917681.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 23]: https://img-blog.csdnimg.cn/2021041013462445.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 24]: https://img-blog.csdnimg.cn/20210410135241475.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[20200614200726115.png]: https://img-blog.csdnimg.cn/20200614200726115.png
[20200614201321887.png]: https://img-blog.csdnimg.cn/20200614201321887.png
[20200614202806132.png]: https://img-blog.csdnimg.cn/20200614202806132.png
[20200614202905582.png]: https://img-blog.csdnimg.cn/20200614202905582.png
[20210410194850338.png]: https://img-blog.csdnimg.cn/20210410194850338.png
[20210410194901838.png]: https://img-blog.csdnimg.cn/20210410194901838.png
[20210410194954243.png]: https://img-blog.csdnimg.cn/20210410194954243.png
[2021041020081759.png]: https://img-blog.csdnimg.cn/2021041020081759.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 25]: https://img-blog.csdnimg.cn/20210410195654712.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 26]: https://img-blog.csdnimg.cn/20210410195832482.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70
[Link 7]: https://dev.mysql.com/doc/refman/8.0/en/optimizing-innodb-queries.html
[20210411121210298.png]: https://img-blog.csdnimg.cn/20210411121210298.png
[2021041112240957.png]: https://img-blog.csdnimg.cn/2021041112240957.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 27]: https://img-blog.csdnimg.cn/20200614234941635.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw,size_16,color_FFFFFF,t_70