【MySQL】索引原理（一）：索引的存储结构是什么？数组？链表？树？

忘是亡心i 2022-11-20 12:56 130阅读 0赞

索引是什么？

> 索引是帮助 MySQL **高效**获取数据的**排好序**的**数据结构**

第一个问题，为什么说索引能高效获取数据呢？

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center]

首先数据是以文件的形式存放在磁盘上面的，每一行数据都有它的磁盘地址。如果没有索引的话，要从500万行数据里面检索一条数据，只能依次遍历这张表的全部数据，直到找到这条数据。

但是有了索引之后，只需要在索引里面去检索这条数据就行了，因为它是一种特殊的专门用来快速检索的数据结构，我们找到数据存放的磁盘地址以后，就可以拿到数据了。

就像我们从一本 500 页的书里面去找特定的一小节的内容，肯定不可能从第一页开始翻。那么这本书有专门的目录，它可能只有几页的内容，它是按页码来组织的，可以根据拼音或者偏旁部首来查找，只要确定内容对应的页码，就能很快地找到我们想要的内容。

> 索引都有什么类型？在InnoDB 里面，索引类型有三种，普通索引、唯一索引（主键索引是特殊的唯一索引）、全文索引。
> 
>  *  普通（Normal）：也叫非唯一索引，是最普通的索引，没有任何的限制。
>  *  唯一（Unique）：唯一索引要求键值不能重复。另外需要注意的是，主键索引是一种特殊的唯一索引，它还多了一个限制条件，要求键值不能为空。主键索引用primaykey创建。
>  *  全文（Fulltext）：针对比较大的数据，比如我们存放的是消息内容，有几KB的数据的这种情况，如果要解决like查询效率低的问题，可以创建全文索引。只有文本类型的字段才可以创建全文索引，比如char、varchar、text。

明白了第一个问题，那还剩下一个问题。我们说索引是一种数据结构，那么它到底应该选择一种什么数据结构，才能实现数据的高效检索呢，并且将所有数据排好序呢？我们就带着问题向下看…

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

## 1.数组/链表 ##

> 双十一过去之后，你女朋友跟你玩了一个猜数字的游戏。猜猜我昨天买了多少钱，给你五次机会。
> 
>   
> 10000？低了。30000？高了。接下来你会猜多少？  
> 20000。为什么你不猜11000，也不猜29000呢？

其实这个就是**二分查找**的一种思想，也叫折半查找，每一次，我们都把候选数据缩小了一半。如果数据已经排过序的话，这种方式效率比较高。

所以第一个，我们可以考虑用有序数组作为索引的数据结构。有序数组的等值查询和比较查询效率非常高，但是更新数据的时候会出现一个问题，可能要挪动大量的数据（改变index），所以只适合存储静态的数据。

为了支持频繁的修改，比如插入数据，我们需要采用链表。链表的话，如果是单链表，它的查找效率还是不够高。所以，有没有可以使用二分查找的链表呢？为了解决这个问题，BST（Binary SearchTree）也就是我们所说的二叉查找树诞生了。

## 2.二叉查找树（BST Binary Search Tree） ##

二叉查找树的特点是什么？左子树所有的节点都小于父节点，右子树所有的节点都大于父节点。投影到平面以后，就是一个有序的线性表。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 1]

二叉查找树既能够实现快速查找，又能够实现快速插入。但是二叉查找树有一个问题：就是它的查找耗时是和这棵树的深度相关的，在最坏的情况下时间复杂度会退化成O(n)。比如，我们插入的数据刚好是有序的，比如 \[2、6、11、13、17、22\] 这个时候我们的二叉查找树变成了什么样了呢？

它会变成链表（我们把这种树叫做“斜树”），这种情况下不能达到加快检索速度的目的，和顺序查找效率是没有区别的。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 2][]

造成它倾斜的原因是什么呢？因为左右子树深度差太大，这棵树的左子树根本没有节点——也就是它不够平衡。

所以，我们有没有左右子树深度相差不是那么大，更加平衡的树呢？这个就是平衡二叉树，叫做Balanced binary search trees，或者AVL树（AVL 是发明这个数据结构的人的名字）。

## 3.平衡二叉树（AVL Tree）（左旋、右旋） ##

平衡二叉树的定义：左右子树深度差绝对值不能超过1。

是什么意思呢？比如左子树的深度是2，右子树的深度只能是1或者3。这个时候我们再按顺序插入1、2、3、4、5、6，一定是这样，不会变成一棵“斜树” 。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 3]

那它的平衡是怎么做到的呢？怎么保证左右子树的深度差不能超过1呢？ 拿插入1、2、3 来说吧，当我们插入了1、2 之后，如果按照二叉查找树的定义，3 肯定是要在 2 的右边的，这个时候根节点1的右节点深度会变成 2，但是左节点的深度是 0，因为它没有子节点，所以就会违反平衡二叉树的定义。那应该怎么办呢？

因为它是右节点下面接一个右节点，右-右型，所以这个时候我们要把2提上去，这个操作叫做左旋。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 4]

同样的，如果我们插入7、6、5，这个时候会变成左左型，就会发生右旋操作，把 6 提上去。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 5]

所以为了保持平衡，AVL树在插入和更新数据的时候执行了一系列的计算和调整的操作。

**索引应该存储什么内容？**

平衡的问题我们解决了，那么平衡二叉树作为索引怎么查询数据？在平衡二叉树中，一个节点，它的大小是一个固定的单位，作为索引应该存储什么内容？它应该存储三块的内容：

*  第一个是索引的键值。比如我们在id上面创建了一个索引，我在用 where id=1 的条件查询的时候就会找到索引里面的id的这个键值。
 *  第二个是数据的磁盘地址，因为索引的作用就是去查找数据的存放的地址。
 *  第三个，因为是二叉树，它必须还要有左子节点和右子节点的引用，这样我们才能找到下一个节点。比如大于26的时候，走右边，到下一个树的节点，继续判断。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 6]

**如果是这样存储数据的话，会存在什么问题？**

首先，索引的数据，是放在硬盘上的。当我们用树的结构来存储索引的时候，访问一个节点就要跟磁盘之间发生一次IO。**InnoDB操作磁盘的最小的单位是一页**（或者叫一个磁盘块），大小是16K(16384字节)。那么，一个树的节点就是16K的大小。如果我们一个节点只存一个键值+数据+引用，例如整形的字段，可能只用了十几个或者几十个字节，它远远达不到16K的容量，所以访问一个树节点，进行一次IO的时候，浪费了大量的空间。

所以如果每个节点存储的数据太少，从索引中找到我们需要的数据，就要访问更多的节点，意味着跟磁盘交互次数就会过多。如果是机械硬盘时代，每次从磁盘读取数据需要10ms左右的寻址时间，交互次数越多，消耗的时间就越多。

比如上面这张图，我们一张表里面有6条数据，当我们查询id=37的时候，要查询两个子节点，就需要跟磁盘交互3 次，如果我们有几百万的数据呢？这个时间更加难以估计。

**所以，解决方案是什么呢？**

可以从下面两点去优化：

*  第一，让每个节点存储更多的数据。
 *  第二，节点上的关键字的数量越多，我们的指针数也越多，也就是意味着可以有更多的分叉（我们把它叫做“路数”）。因为分叉数越多，树的深度就会减少（根节点是0）。这样，我们的树是不是从原来的高瘦高瘦的样子，变成了矮胖矮胖的样子？这个时候，我们的树就不再是二叉了，而是多叉，或者叫做多路。

## 4.多路平衡查找树（B Tree）（分裂、合并） ##

Balanced Tree，这个就是我们的多路平衡查找树，叫做B Tree（B代表平衡）。跟AVL树一样，B树在枝节点和叶子节点存储键值、数据地址、节点引用。它有一个特点：分叉数（路数）永远比关键字数多1。比如我们画的这棵树，每个节点存储两个关键字（索引数据），那么就会有三个指针指向三个子节点。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 7]

B Tree的查找规则是什么样的呢？比如我们要在这张表里面查找15。

1.  因为15小于17，走左边。
2.  因为15大于12，走右边。

在磁盘块7里面就找到了15，只用了3次IO。

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

这个是不是比AVL 树效率更高呢？那BTree又是怎么实现一个节点存储多个关键字，还保持平衡的呢？跟AVL树有什么区别？ 比如MaxDegree（路数）是3的时候，我们插入数据1、2、3，在插入3的时候，本来应该在第一个磁盘块，但是如果一个节点有三个关键字的时候，意味着有 4个指针，子节点会变成 4 路，所以这个时候必须进行分裂。把中间的数据2提上去，把1和3变成2的子节点。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 8]

如果删除节点，会有相反的合并的操作。注意这里是分裂和合并，跟AVL树的左旋和右旋是不一样的。我们继续插入4和5，B Tree又会出现分裂和合并的操作。

节点的分裂和合并，其实就是InnoDB页的分裂和合并。

## 5.B+树（加强版多路平衡查找树） ##

B Tree 的效率已经很高了，为什么 MySQL 还要对 B Tree 进行改良，最终使用了B+Tree呢？总体上来说，这个B树的改良版本解决的问题比B Tree更全面。我们来看一下InnoDB里面的B+树的存储结构：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 9]

MySQL中的B+Tree有几个特点：

1.  它的关键字的数量是跟路数相等的；
2.  B+Tree 的根节点和枝节点中都不会存储数据，只有叶子节点才存储数据。搜索到关键字不会直接返回，会到最后一层的叶子节点。
    
     *  比如我们搜索 id=28，虽然在第一层直接命中了，但是全部的数据在叶子节点上面，所以我还要继续往下搜索，一直到叶子节点。
     *  假设一条记录是1K，一个叶子节点（一页）可以存储16条记录。非叶子节点可以存储多少个指针？  
        假设索引字段是bigint 类型，长度为 8 字节。指针大小在 InnoDB 源码中设置为 6 字节，这样一共 14 字节。非叶子节点（一页）可以存储16384/14=1170个这样的单元（键值+指针），代表有1170个指针。树深度为 2 的时候 ， 有 1170 ^2 个 叶子节点 ， 可以存储的数据为 `1170*1170*16=21902400`
    
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 10]
    
    在查找数据时一次页的查找代表一次 IO，也就是说，一张2000万左右的表，查询数据最多需要访问3次磁盘。所以在 InnoDB 中 B+ 树深度一般为 1-3 层，它就能满足千万级的数据存储。
3.  B+Tree的每个叶子节点增加了一个指向相邻叶子节点的指针，它的最后一个数据会指向下一个叶子节点的第一个数据，形成了一个有序链表的结构。
4.  它是根据左闭右开的区间 \[ )来检索数据。我们来看一下B+Tree的数据搜寻过程：
    
    1.  比如我们要查找 28，在根节点就找到了键值，但是因为它不是页子节点，所以会继续往下搜寻，28是\[28,66)的左闭右开的区间的临界值，所以会走中间的子节点，然后继续搜索，它又是\[28,34)的左闭右开的区间的临界值，所以会走左边的子节点，最后在叶子节点上找到了需要的数据。
    2.  如果是范围查询，比如要查询从22到60的数据，当找到22之后，只需要顺着节点和指针顺序遍历就可以一次性访问到所有的数据节点，这样就极大地提高了区间查询效率（不需要返回上层父节点重复遍历查找）。

总结一下，InnoDB中的B+Tree的特点：

1.  它是BTree的变种，BTree能解决的问题，它都能解决。BTree解决的两大问题是什么？（每个节点存储更多关键字；路数更多）
2.  扫库、扫表能力更强（如果我们要对表进行全表扫描，只需要遍历叶子节点就可以了，不需要遍历整棵B+Tree拿到所有的数据）
3.  B+Tree的磁盘读写能力相对于BTree来说更强（根节点和枝节点不保存数据区，所以一个节点可以保存更多的关键字，一次磁盘加载的关键字更多）
4.  排序能力更强（因为叶子节点上有下一个数据区的指针，数据形成了链表）
5.  效率更加稳定（B+Tree永远是在叶子节点拿到数据，所以IO次数是稳定的）

## 6.为什么不用红黑树？ ##

红黑树也是BST树，但是不是严格平衡的。必须满足5个约束：

1.  节点分为红色或者黑色。
2.  根节点必须是黑色的。
3.  叶子节点都是黑色的NULL节点。
4.  红色节点的两个子节点都是黑色（不允许两个相邻的红色节点）。
5.  从任意节点出发，到其每个叶子节点的路径中包含相同数量的黑色节点。

比如插入：60、56、68、45、64、58、72、43、49

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 11]

基于以上规则，可以推导出：从根节点到叶子节点的最长路径（红黑相间的路径）不大于最短路径（全部是黑色  
节点）的2倍。

为什么不用红黑树？1、只有两路；2、不够平衡。红黑树一般只放在内存里面用。例如Java的TreeMap。

## 7.哈希表也能作为索引？ ##

在Navicat的工具中，创建索引，索引方式有两种，Hash和BTree。BTree上面说了，而Hash是以KV的形式检索数据，也就是说，它会根据索引字段生成哈希码和指针，指针指向数据。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 12]

哈希索引有什么特点呢？

1.  它的时间复杂度是O(1)，查询速度比较快。因为哈希索引里面的数据不是按顺序存储的，所以不能用于排序。
2.  我们在查询数据的时候要根据键值计算哈希码，所以它只能支持等值查询（= IN），不支持范围查询（> < >= <= between and）。
3.  如果字段重复值很多的时候，会出现大量的哈希冲突（采用拉链法解决），效率会降低。

**InnoDB可以在客户端创建一个索引，使用哈希索引吗？**

InnoDB 只支持显式创建 B+Tree 索引，对于一些热点数据页，InnoDB会自动建立自适应Hash索引，也就是在B+Tree索引基础上建立Hash索引，这个过程对于客户端是不可控制的，隐式的。

我们在Navicat工具里面选择索引方法是哈希，但是它创建的还是B+Tree索引，这个不是我们可以手动控制的。[上篇][Link 1]我们说到 buffer pool里面有一块区域是 **Adaptive Hash Index** 自适应哈希索引，就是这个。

这个开关默认是ON：

show variables like 'innodb_adaptive_hash_index';

![在这里插入图片描述][20201028225031445.png_pic_center]

最后，因为BTree和B+Tree的特性，它们广泛地用在文件系统和数据库中，例如Windows的HPFS文件系统，Oracel、MySQL、SQLServer数据库。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center]: /images/20221120/1fcac452cfb84c46825bb47b7a33f516.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 1]: https://img-blog.csdnimg.cn/20201216160847730.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 2]: https://img-blog.csdnimg.cn/2020102822202355.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 3]: https://img-blog.csdnimg.cn/20201028222100215.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 4]: https://img-blog.csdnimg.cn/20201028222143529.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 5]: https://img-blog.csdnimg.cn/20201028222159226.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 6]: https://img-blog.csdnimg.cn/20201216155243762.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 7]: https://img-blog.csdnimg.cn/20201216155408826.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 8]: https://img-blog.csdnimg.cn/20201216155627393.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 9]: https://img-blog.csdnimg.cn/20201104171341974.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 10]: https://img-blog.csdnimg.cn/20201216160731496.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 11]: https://img-blog.csdnimg.cn/20201028224814866.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 12]: https://img-blog.csdnimg.cn/20201216163659219.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw==,size_16,color_FFFFFF,t_70#pic_center
[Link 1]: https://blog.csdn.net/weixin_43935927/article/details/109324415
[20201028225031445.png_pic_center]: https://img-blog.csdnimg.cn/20201028225031445.png#pic_center