[Java大厂必备面试题] 点滴促就辉煌, 每日三题【Day14】:数据库3

痛定思痛。 2023-10-02 12:28 8阅读 0赞

**目录**

面试题1：MySQL有哪些数据类型？

追问1：char 和 varchar 的区别是什么？

1、固定长度 & 可变长度

2、存储方式

3、存储容量

4、思考：既然VARCHAR长度可变，那我要不要定到最大?

5、在SQL中需要注意的点

追问2：varchar(50)、char(50)中50的涵义是什么？

追问3：那int(10)中10的涵义呢？int(1)和int(20)有什么不同？

面试题2：MySQL 的内连接、左连接、右连接有什么区别？

面试题3：MySQL的隐式转换问题遇到过么？说说你的理解。

1、SQL语句中隐式转换的坑

2、黑客同学喜欢用隐式转换进行SQL注入攻击

3、索引中隐式转换的坑

1、索引失效

2、查询结果不准确

每日小结

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

> 大家好,我是来自程序员的家的一名卑微搬砖人， 无聊就要搬砖一下，寻求忙碌的真谛

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

本栏目Java开发岗高频面试题主要出自以下各技术栈：`Java基础知识`、`集合容器`、`并发编程`、`JVM`、`Spring全家桶`、`MyBatis等ORMapping框架`、`MySQL数据库`、`Redis缓存`、`RabbitMQ消息队列`、`Linux操作技巧`等。

## 面试题1：MySQL有哪些数据类型？ ##

MySQL支持多种类型，大致可以分为三类：`数值`、`日期/时间`和`字符串(字符)`类型。

**数值类型**

`MySQL支持所有标准SQL数值数据类型。`

这些类型包括严格数值数据类型(`INTEGER、SMALLINT、DECIMAL和NUMERIC`)，以及近似数值数据类型(`FLOAT、REAL和DOUBLE PRECISION`)。

> 关键字INT是INTEGER的同义词，关键字DEC是DECIMAL的同义词。

BIT数据类型保存位字段值，并且支持MyISAM、MEMORY、InnoDB和BDB表。

作为SQL标准的扩展，MySQL也支持整数类型`TINYINT、SMALLINT、MEDIUMINT、INT和BIGINT`。分别使用`8、16、24、32、64`位存储空间，

他们存储值的范围为：**-2(n-1) ~ 2(n-1)-1**，其中N是存储空间的位数。

下表显示了需要的每个整数类型的存储和范围。

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5piv5rGk5ZyG5Lir_size_20_color_FFFFFF_t_70_g_se_x_16][]

**日期和时间类型**

表示时间值的日期和时间类型为DATETIME、DATE、TIMESTAMP、TIME和YEAR。

每个时间类型有一个有效值范围和一个"零"值，当指定不合法的MySQL不能表示的值时使用"零"值。

TIMESTAMP类型有专有的自动更新特性，将在后面描述。

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5piv5rGk5ZyG5Lir_size_20_color_FFFFFF_t_70_g_se_x_16 1][]

**字符串类型**

字符串类型指`CHAR、VARCHAR、BINARY、VARBINARY、BLOB、TEXT、ENUM和SET`。该节描述了这些类型如何工作以及如何在查询中使用这些类型。

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5piv5rGk5ZyG5Lir_size_20_color_FFFFFF_t_70_g_se_x_16 2][]

> 注意：
> 
>  *  char(n) 和 varchar(n) 中括号中 n 代表字符的个数，并不代表字节个数，比如 CHAR(30) 就可以存储 30 个字符。
>  *  CHAR 和 VARCHAR 类型类似，但它们保存和检索的方式不同。它们的最大长度和是否尾部空格被保留等方面也不同。在存储或检索过程中不进行大小写转换。
>  *  BINARY 和 VARBINARY 类似于 CHAR 和 VARCHAR，不同的是它们包含二进制字符串而不要非二进制字符串。也就是说，它们包含字节字符串而不是字符字符串。这说明它们没有字符集，并且排序和比较基于列值字节的数值值。
>  *  BLOB 是一个二进制大对象，可以容纳可变数量的数据。有 4 种 BLOB 类型：TINYBLOB、BLOB、MEDIUMBLOB 和 LONGBLOB。它们区别在于可容纳存储范围不同。
>  *  有 4 种 TEXT 类型：TINYTEXT、TEXT、MEDIUMTEXT 和 LONGTEXT。对应的这 4 种 BLOB 类型，可存储的最大长度不同，可根据实际情况选择。

### 追问1：char 和 varchar 的区别是什么？ ###

#### 1、固定长度 & 可变长度 ####

*  VARCHAR

VARCHAR类型用于存储可变长度字符串，是最常见的字符串数据类型。它比固定长度类型更节省空间，因为它仅使用必要的空间(根据实际字符串的长度改变存储空间)。  
  有一种情况例外，如果MySQL表使用ROW\_FORMAT=FIXED创建的话，每一行都会使用定长存储。

CHAR  
  CHAR类型用于存储固定长度字符串：MySQL总是根据定义的字符串长度分配足够的空间。当存储CHAR值时，MySQL会删除字符串中的末尾空格(在MySQL 4.1和更老版本中VARCHAR 也是这样实现的——也就是说这些版本中CHAR和VARCHAR在逻辑上是一样的，区别只是在存储格式上)。  
  同时，CHAR值会根据需要采用空格进行剩余空间填充，以方便比较和检索。但正因为其长度固定，所以会占据多余的空间，也是一种空间换时间的策略；

#### 2、存储方式 ####

*  VARCHAR

VARCHAR需要使用1或2个额外字节记录字符串的长度：如果列的最大长度小于或等于255字节，则只使用1个字节表示，否则使用2个字节。假设采用latinl字符集，一个VARCHAR(10)的列需要11个字节的存储空间。VARCHAR(1000)的列则需要1002 个字节，因为需要2个字节存储长度信息。

VARCHAR节省了存储空间，所以对性能也有帮助。但是，由于行是变长的，在UPDATE时可能使行变得比原来更长，这就导致需要做额外的工作。如果一个行占用的空间增长，并且在页内没有更多的空间可以存储，在这种情况下，不同的存储引擎的处理方式是不一样的。例如，MylSAM会将行拆成不同的片段存储，InnoDB则需要分裂页来使行可以放进页内。

*  CHAR

CHAR适合存储很短或长度近似的字符串。例如，CHAR非常适合存储密码的MD5值，因为这是一个定长的值。对于经常变更的数据，CHAR也比VARCHAR更好，因为定长的CHAR类型不容易产生碎片。对于非常短的列，CHAR比VARCHAR在存储空间上也更有效率。例如用CHAR(1)来存储只有Y和N的值，如果采用单字节字符集只需要一个字节，但是VARCHAR(1)却需要两个字节，因为还有一个记录长度的额外字节。

#### 3、存储容量 ####

*  CHAR

对于char类型来说，最多只能存放的字符个数为255，和编码无关，任何编码最大容量都是255。

*  VARCHAR

MySQL行默认最大65535字节，是所有列共享（相加）的，所以VARCHAR的最大值受此限制。

表中只有单列字段情况下，varchar一般最多能存放(65535 - 3)个字节，varchar的**最大有效长度**通过**最大行数据长度**和使用的字符集来确定，通常的最大长度是65532个字符（当字符串中的字符都只占1个字节时，能达到65532个字符）；

为什么是65532个字符？算法如下（有余数时向下取整）：

> > 最大长度(字符数) = （行存储最大字节数 - NULL标识列占用字节数 - 长度标识字节数） / 字符集单字符最大字节数

*  **`NULL标识列占用字节数`**：允许NULL时，占一字节
 *  **`长度标识字节数`**：记录长度的标识，长度小于等于255（28）时，占1字节；小于65535时（216）,占2字节

VARCHAR类型在4.1和5.0版本发生了很大的变化，使得情况更加复杂。从MySQL 4.1开始，每个字符串列可以定义自己的字符集和排序规则。这些东西会很大程度上影响性能。

*  4.0版本及以下，MySQL中varchar长度是按`字节`展示，如varchar(20)，指的是20`字节`；
 *  5.0版本及以上，MySQL中varchar长度是按`字符`展示。如varchar(20)，指的是20`字符`。

当然，`行`总长度还是65535字节，而字符和字节的换算，则与编码方式有关，不同的字符所占的字节是不同的。编码划分如下：

> **`GBK编码：`**  
> 一个英文字符占一个字节，中文2字节，单字符最大可占用2个字节。
> 
> **`UTF-8编码：`**  
> 一个英文字符占一个字节，中文3字节，单字符最大可占用3个字节。
> 
> **`utf8mb4编码：`**  
> 一个英文字符占一个字节，中文3字节，单字符最大占4个字节（如emoji表情4字节）。

假设当前还有6字节可以存放字符，按单字符占用最大字节数来算，可以存放3个GBK、或2个utf8、或1个utf8mb4。

#### 4、思考：既然VARCHAR长度可变，那我要不要定到最大? ####

没错，相信你已经有答案了，别这么干！

`就像使用VARCHAR(5)和VARCHAR(200)存储 '陈哈哈'的磁盘空间开销是一样的。那么使用更短的列有什么优势呢？`

事实证明有很大的优势。更长的列会消耗更多的内存，因为MySQL通常会分配固定大小的内存块来保存内部值。

当然，在没拿到存储引擎存储的数据之前，并不会知道我这一行拿出来的数据到底有多长，可能长度只有1，可能长度是500，那怎么办呢？那就只能**`先把最大空间分配好了，避免放不下的问题发生，这样实际上对于真实数据较短的varchar确实会造成空间的浪费。`**

举例：我向数据类型为：varchar（1000）的列插入了1024行数据，但是每个只存一个字符，那么这1024行真实数据量其实只有1K，但是我却需要约1M的内存去适应他。所以最好的策略是只分配真正需要的空间。

#### 5、在SQL中需要注意的点 ####

下面通过一个具体的示例来说明CHAR和VARCHAR类型存储时的区别。我们创建一张同时存在`CHAR(10)`字段、`VARCHAR(10)`字段的表，并且往里面插入一些值来做对比验证：

>     -- 建表语句
>     CREATE TABLE `str_table` (
>       `id` int(11) NOT NULL AUTO_INCREMENT,
>       `str_char` char(10) DEFAULT NULL,
>       `str_varchar` varchar(10) DEFAULT NULL,
>       PRIMARY KEY (`id`)
>     ) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8mb4;

分别插入一些字符串前面和后面都有空格的示例

>     -- 插入测试数据
>     INSERT INTO `str_table` (`id`, `str_char`, `str_varchar`) 
>     VALUES 
>     (null, '陈哈哈', '陈哈哈'),
>     (null, '  陈哈哈', '  陈哈哈'),
>     (null, '陈哈哈  ', '陈哈哈  ');

测试数据查询语句如下，通过拼接能更好的看出对比效果：

>     -- 测试数据查询
>     select id,concat("|",str_char,"|") as `char`,concat("|",str_varchar,"|") as `varchar` from str_table;

> mysql> select id,concat("|",str\_char,"|") as \`char\`,concat("|",str\_varchar,"|") as \`varchar\` from str\_table;  
> \+----+---------------+---------------+  
> | id | char | varchar |  
> \+----+---------------+---------------+  
> | 6 | |陈哈哈| | |陈哈哈| |  
> | 7 | | 陈哈哈| | | 陈哈哈| |  
> | 8 | |陈哈哈| | |陈哈哈 | |  
> \+----+---------------+---------------+  
> 3 rows in set (0.00 sec)  
>

*  当检索这些值的时候，会发现id=8行中，char类型的"陈哈哈 "末尾的空格被截断了，而VARCHAR(10)字段存储相同的值时，末尾的空格被保留了。
 *  另外，id=7行的数据前面空格都被保留了。

可见，CHAR会默认切掉字符串末尾的空格，如果需要保留末尾的空格，记得用varchar类型！

### 追问2：varchar(50)、char(50)中50的涵义是什么？ ###

**varchar(50)**

VARCHAR列中的值为可变长字符串。长度可以指定为0到65535之间的值。VARCHAR的最大有效长度由最大行大小和使用的字符集确定。

**MySQL 4.1之前**：VARCHAR(50)的“50”指的是50字节（bytes）。如果存放UTF8汉字时，那么最多只能存放16个（每个汉字3字节）。  
**MySQL 4.1版本及以后**：VARCHAR(50)的“50”指的是50字符（character），无论存放的是数字、字母还是UTF8汉字（每个汉字3字节），都可以存放50个。

**char(50)**

CHAR和VARCHAR类型声明的长度表示保存的最大字符数。例如，CHAR(30)可以占用30个字符。

对于MyISAM表，推荐CHAR类型；对于InnoDB表，推荐VARCHAR类型。

另外，在进行检索的时候，若列值的尾部含有空格，则CHAR列会删除其尾部的空格，而VARCHAR则会保留空格。

### 追问3：那int(10)中10的涵义呢？int(1)和int(20)有什么不同？ ###

**int的范围**

有符号的整型范围是-2147483648~2147483647 （-2^32 ~ 2^32）  
无符号的整型范围是0~4294967295

**int(10)的意思**

int(10)的意思是假设有一个变量名为id，它的能显示的宽度能显示10位。在使用id时，假如我给id输入10，那么mysql会默认给你存储0000000010。

当你输入的数据不足10位时，会自动帮你补全位数。

假如我设计的id字段是int(20)，那么我输入id = 10时，mysql会自动补全18个0（00000000000000000010），补到20位为止。

引用一下《高性能MySQL》的说明：

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5piv5rGk5ZyG5Lir_size_20_color_FFFFFF_t_70_g_se_x_16 3][]

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

太难了！！！

![ab5e7f5084037f3ee19bb06bb4868c4e.png][]

## 面试题2：MySQL 的内连接、左连接、右连接有什么区别？ ##

例：ab两表关联，a表数据有，b表关联数据没有，a表的就不要显示或显示null的问题；几个连接怎么使用，总结一下：

`左链接取A集合，右链接取B集合，full join取并集，inner join 取交集。`

## 面试题3：MySQL的隐式转换问题遇到过么？说说你的理解。 ##

#### 1、SQL语句中隐式转换的坑 ####

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5piv5rGk5ZyG5Lir_size_20_color_FFFFFF_t_70_g_se_x_16 4][]

翻译成人话：

1.  两个参数至少有一个是 NULL 时，比较的结果也是 NULL，例外是使用 <=> 对两个 NULL 做比较时会返回 1，这两种情况都不需要做类型转换。
2.  两个参数都是字符串，会按照字符串来比较，不做类型转换
3.  两个参数都是整数，按照整数来比较，不做类型转换
4.  十六进制的值和非数字做比较时，会被当做二进制串
5.  有一个参数是 TIMESTAMP 或 DATETIME，并且另外一个参数是常量，常量会被转换为 timestamp
6.  有一个参数是 decimal 类型，如果另外一个参数是 decimal 或者整数，会将整数转换为 decimal 后进行比较，如果另外一个参数是浮点数，则会把 decimal 转换为浮点数进行比较
7.  所有其他情况下，两个参数都会被转换为浮点数再进行比较。（这里所说的浮点数一般默认为double类型）

可以看到，非前六种以外的类型转换都要转成浮点类型来处理，这意味着什么？意味着MySQL承认了隐式转换这个事儿，**还表示`不爱看官方文档的哥们儿出问题活该`~~**

？what

![bbf55bfe9df14bec95f0fa11da514cf6.png][]

我们用一些具体示例来看一下，通过下述SQL可见，当1234没有引号也就是整数时，`'1234abcd' = 1234 → true`，说明MySQL对`'1234abcd'做了转型，转成了浮点类型`，结果是：1234abcd => 1234

>     # 0：false；1：true
>     mysql> SELECT '1234abcd' = '1234';
>     +---------------------+
>     | '1234abcd' = '1234' |
>     +---------------------+
>     |                   0 |
>     +---------------------+
>     1 row in set (0.00 sec)
>     
>     # 0：false；1：true
>     mysql> SELECT '1234abcd' = 1234;
>     +-------------------+
>     | '1234abcd' = 1234 |
>     +-------------------+
>     |                 1 |
>     +-------------------+
>     1 row in set, 1 warning (0.00 sec)

为啥1234abcd => 1234呢？ 其实’1234’和’abcd’都会转成浮点数，即：**`1234+0=1234`**，非数字类型的都被直接转成了 0

>     mysql> SELECT '1234' + 'abcd';
>     +-----------------+
>     | '1234' + 'abcd' |
>     +-----------------+
>     |            1234 |
>     +-----------------+
>     1 row in set, 1 warning (0.00 sec)

你发现了什么？原来字符串涉及到`+`、`=`、`-`、`/` 等等运算符时都会进行隐式转型，也就是转成`double`，那么字符串转double是怎么转的呢？

> \# 转成：'1aaaa' = 1  
> mysql> SELECT '1aaaa' = 1;  
> \+-------------+  
> | '1aaaa' = 1 |  
> \+-------------+  
> | 1 |  
> \+-------------+  
> 1 row in set, 1 warning (0.00 sec)
> 
> \# 转成：'a1111' = 0  
> mysql> SELECT 'a1111' = 1;  
> \+-------------+  
> | 'a1111' = 1 |  
> \+-------------+  
> | 0 |  
> \+-------------+  
> 1 row in set, 1 warning (0.00 sec)
> 
> \# 转成：0 + 0 =0  
> mysql> SELECT 'aa' + 'aa' = 1;  
> \+-----------------+  
> | 'aa' + 'aa' = 1 |  
> \+-----------------+  
> | 0 |  
> \+-----------------+  
> 1 row in set, 2 warnings (0.00 sec)
> 
> \# 转成：0 + 0 + 1 =1  
> mysql> SELECT 'aa' + 'aa' + '1' = 1;  
> \+-----------------------+  
> | 'aa' + 'aa' + '1' = 1 |  
> \+-----------------------+  
> | 1 |  
> \+-----------------------+  
> 1 row in set, 2 warnings (0.00 sec)

可见，是以字符串从左向右取值的，且从非数字起后面的值都被转成 `0`，如`a11111`，第一位为`a`,则整体转为`0`；`1aaaa`第一位为`1`,第二位为`a`，从第二位往后转成`0`，得`a11111` → `0`

>     mysql> SELECT * from t_user where `password`=1234;
>     +----+-----------+----------+
>     | id | username  | password |
>     +----+-----------+----------+
>     |  2 | 侨布斯    | 1234     |
>     |  3 | 提莫      | 1234abcd |
>     +----+-----------+----------+
>     2 rows in set, 1 warning (0.00 sec)

现在我们就明白为什么能匹配到**`提莫`**了。因为在不同类型转换时"1234abcd"被转成了浮点类型，"abcd"转成浮点型后为**`0`**，因此MySQL判为：“1234abcd” = ‘1234’ + 0 。

#### 2、黑客同学喜欢用隐式转换进行SQL注入攻击 ####

通过第一部分隐式转换的了解，我们可以预测一些简单SQL注入的方式：

> mysql> SELECT \* from t\_user where username='陈哈哈' and \`password\`=0;  
> \+----+-----------+----------+  
> | id | username | password |  
> \+----+-----------+----------+  
> | 1 | 陈哈哈 | abcd1234 |  
> \+----+-----------+----------+  
> 1 row in set, 1 warning (0.00 sec)  
>

果然，我账号的密码被毫无意外的攻破了。。。想想账号被陌生人登录，保存多年的资源被泄露................例如林正英僵尸电影大全

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5piv5rGk5ZyG5Lir_size_17_color_FFFFFF_t_70_g_se_x_16][]

如果有些朋友公司的网站用的是下面的写法：

>     select * from t_user where username=${username} and `password`=${password};

**  不然有些小伙伴友好的把请求参数构建成 username → `a' OR 1='1` ，那么password是啥都无所谓了，是吧**

> 快改！！！

当然，其实很多注入攻击的真实目的，并不是用来破解用户账号的，而是破坏服务器。一般我们在页面F12发现有问题的接口后，通过脚本模拟请求参数（构造注入参数），去不断尝试自定义构造limit、order、where等条件，或许花不了多久就能通过一个不规范的请求入口，检索出该表甚至其他大表全量信息。导致公司服务器负载异常，连接数打满，CPU200%等有趣的情况。有兴趣的同学可以花几小时尝试破解自己公司的web~~

#### 3、索引中隐式转换的坑 ####

同理，在MySQL根据索引进行查询时，如果你的username字段有索引且为varchar类型，且查询如下时：

> select \* from t\_user where username=123;

该SQL会出现两个问题：

#### 1、索引失效 ####

无法使用到索引查询，因为mysql会在引擎层进行类型隐式转换（CONVERT\_IMPLICIT），会先把username隐式转换成浮点数，然后再跟你的123进行比较，然而你的索引是建在username上的，并不是在转换后的username上的，所以进行转换后的username相当于没有索引。会全表扫描，换做大表中，无法使用索引，你懂得。

#### **2、查询结果不准确** ####

第一部分我们已经举例说明，MySQL在隐式转换时的varchar转double，会出现很多意想不到的情况，比如 “123”，" 123"，"123a"都会转成123，实际场景中都是不允许出现的。

## 每日小结 ##

下班-------->

原文链接：https://blog.csdn.net/qq\_39390545/article/details/118230111

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5piv5rGk5ZyG5Lir_size_20_color_FFFFFF_t_70_g_se_x_16]: https://img-blog.csdnimg.cn/a7c5f4350ffe4a9d821e39dbabc5cb28.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA5piv5rGk5ZyG5Lir,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5piv5rGk5ZyG5Lir_size_20_color_FFFFFF_t_70_g_se_x_16 1]: https://img-blog.csdnimg.cn/cbeca0e8d5364aaf86eb54682ba936ae.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA5piv5rGk5ZyG5Lir,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5piv5rGk5ZyG5Lir_size_20_color_FFFFFF_t_70_g_se_x_16 2]: https://img-blog.csdnimg.cn/aaafedeebd2549f5bbc10df00c0c9356.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA5piv5rGk5ZyG5Lir,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5piv5rGk5ZyG5Lir_size_20_color_FFFFFF_t_70_g_se_x_16 3]: https://img-blog.csdnimg.cn/8a9d06bb2ef04f33abe2418bd51844e2.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA5piv5rGk5ZyG5Lir,size_20,color_FFFFFF,t_70,g_se,x_16
[ab5e7f5084037f3ee19bb06bb4868c4e.png]: https://img-blog.csdnimg.cn/img_convert/ab5e7f5084037f3ee19bb06bb4868c4e.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5piv5rGk5ZyG5Lir_size_20_color_FFFFFF_t_70_g_se_x_16 4]: https://img-blog.csdnimg.cn/261c4f176a704466a8616e735dcd38cb.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA5piv5rGk5ZyG5Lir,size_20,color_FFFFFF,t_70,g_se,x_16
[bbf55bfe9df14bec95f0fa11da514cf6.png]: https://img-blog.csdnimg.cn/img_convert/bbf55bfe9df14bec95f0fa11da514cf6.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5piv5rGk5ZyG5Lir_size_17_color_FFFFFF_t_70_g_se_x_16]: https://img-blog.csdnimg.cn/90d4e11ec0f34709b2ddb10c7b604e6a.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA5piv5rGk5ZyG5Lir,size_17,color_FFFFFF,t_70,g_se,x_16