MySQL之锁

落日映苍穹つ 2021-08-29 15:39 362阅读 0赞

### 锁 ###

*  1. 什么是锁
 *  2. lock 与 latch
 *  3. InnoDB 中的锁
 *   *  3.1 锁的类型
     *  3.2 一致性非锁定读
     *  3.3 一致性锁定读
     *  3.4 自增长与锁
     *  3.5 外键和锁
 *  4. 锁的算法
 *   *  4.1 行锁的 3 种算法
     *  4.2 解决 Phantom Problem
 *  5. 锁问题
 *   *  5.1 脏读
     *  5.2 不可重复读
     *  5.3 幻读（Phantom Problem）
 *  6. 阻塞
 *  7. 死锁
 *   *  7.1 死锁的概念
     *  7.2死锁的示例
 *  8. 锁升级

# 1. 什么是锁 #

锁机制用于管理对共享资源的并发访问。

数据库系统使用锁是为了支持对共享资源进行并发访问，提供数据的完整性和一致性。

# 2. lock 与 latch #

`latch` 一般被称为闩锁（轻量级的锁），因为其要求锁定的时间必须非常短。在`InnoDB`中，`latch` 又分为 `mutex`（互斥量）和 `rwlock`（读写锁）。其目的是用来保证并发线程操作临界资源的正确性，并且通常没有死锁检测机制。

`lock`的对象是事务，用来锁定的是数据库中的对象，如表、页、行。并且一般 `lock` 的对象仅在事务 `commit` 或 `rollback` 后进行释放（不同事务隔离级别释放的时间可能不同）。`lock`，如大多数数据库中一样，有死锁机制。

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

# 3. InnoDB 中的锁 #

## 3.1 锁的类型 ##

`InnoDB`实现了两种标准的行级锁：

*  共享锁（`S Lock`），允许多个事务读一行数据
 *  排他锁（`X Lock`），只允许一个事务删除或更新一行数据

![在这里插入图片描述][20200601102544634.png]

`X`锁与任何的锁都不兼容，而`S`锁仅和`S`锁兼容。

**`X`锁和`S`锁都是行级锁，兼容是指对同一记录(`row`)锁的兼容性情况**。

为了实现在不同粒度上进行加锁操作（允许事务在行级上的锁和表级上的锁同时存在），`InnoDB`支持一种额外的锁方式，**意向锁**。

意向锁是将对象分为多个层次，意向锁意味着事务希望在更细粒度上进行加锁。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 1]  
       若将上锁的对象看成一棵树，那么对下层的对象上锁，也就是对最细粒度的对象进行上锁，那么首先需要对粗粒度的对象上锁。

如果需要对页上的记录`r` 进行上 `X`锁，那么分别需要对数据库`A`、`表`、`页`上意向锁`IX`，最后对记录`r`上`X`锁。若其中任何一个部分导致等待，那么该操作需要等待粗粒度锁的完成。

InnoDB中的意向锁为表级别的锁。支持两种意向锁：

*  意向共享锁（`IS Lock`），事务想要获得一张表中某几行的共享锁
 *  意向排他锁（`IX Lock`），事务想要获得一张表中某几行的排他锁

为什么要设计意向锁？

考虑这个例子：

事务`A`锁住了表中的**一行**，让这一行只能读，不能写。之后，事务`B`申请**整个表**的写锁。

如果事务`B`申请成功，那么理论上它就能修改表中的任意一行，这与`A`持有的行锁是冲突的。

数据库需要避免这种冲突，就是说要让`B`的申请被阻塞，直到`A`释放了行锁。

数据库要怎么判断这个冲突呢？

`step1`：判断表是否已被其他事务用表锁锁表

`step2`：判断表中的每一行是否已被行锁锁住。

注意`step2`中通过遍历查询，这样的判断方法效率实在不高，因为需要遍历整个表。

于是就有了意向锁。

在意向锁存在的情况下，事务A必须先申请表的意向共享锁，成功后再申请一行的行锁。

在意向锁存在的情况下，上面的判断可以改成

`step1`：判断表是否已被其他事务用表锁锁表

`step2`：发现表上有意向共享锁，说明表中有些行被共享行锁锁住了，因此，事务B申请表的写锁会被阻塞。

最终结论：

**（1）申请意向锁的动作是数据库完成的，就是说，事务`A`申请一行的行锁的时候，数据库会自动先开始申请表的意向锁，不需要程序员使用代码来申请。**

**（2）`IX`，`IS`是表级锁，不会和行级的`X`，`S`锁发生冲突。只会和表级的`X`，`S`发生冲突**。**行级别的X和S按照普通的共享、排他规则即可。所以之前的示例中第2步不会冲突，只要写操作不是同一行，就不会发生冲突。**

## 3.2 一致性非锁定读 ##

一致性非锁定读是指通过`InnoDB`通过行多版本控制的方式来读取当前执行时间数据库中的行数据。

如果读取的行正在执行`DELETE`或`UPDATE`操作，这时读取操作不会因此去等待行上锁的释放。而是`InnoDB`会去读取行的一个快照数据。

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

快照数据指该行之前版本的数据，该实现是通过 `undo` 段来完成，而 `undo` 用来在事务中回滚数据。读取快照数据是不需要上锁的，因为没有事务需要对历史的数据进行修改操作。

可以看到，非锁定机制极大地提高了数据库地并发性。

非锁定读是`InnoDB`默认的读取方式，即读取不会占用和等待表上的锁。但是并不是每个事务隔离级别下都是采用非锁定的一致性读(`Read CoMMITED`和`REPEATABLE READ`采用一致性非锁定读)。**即使使用非锁定读，但是对于快照数据的定义也各不相同**。

快照数据就是当前行数据之前的历史版本，每行记录可能有多个版本。一般称这种技术为行多版本技术。由此带来的并发控制，称为多版本并发控制（`MVCC`）。

在`READ COMMITTED`事务隔离级别下，对于快照数据，非一致性读总是读取被锁定行的最新一份快照数据。

在`REPEATABLE READ`事务隔离级别下，对于快照数据，非一致性读总是读取事务开始时的一份快照数据。

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

会话 `A` 显示地执行命令 `BEGIN` 开启了一个事务，并读取了表 `parent` 中`id` 为`1` 的数据，但是事务并没有结束。于此同时，用户再开启另一个会话 `B`，对会话`B`做如下的操作。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 4]  
       在会话 `B` 中将 `parent` 中 `id` 为 `1` 的记录修改为 `id=3`，但是事务并没有提交，`id=1` 的行其实加了一个`X`锁。此时如果在会话`A`中再次读取 `id` 为 `1` 的记录，根据 `InnoDB` 的特性，即在 `READ COMMITTED` 和 `REPEATABLE READ`下，`InnoDB` 使用非锁定的一致性读。回到事务A，接着未提交的事务，执行刚才的`SQL`，不管是在 `READ COMMITTED` 和 `REPEATABLE READ`下，显示的数据都应该是：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 5]  
       由于当前 `id=1` 的数据被修改了`1`次，因此只有一个行版本记录。接着，在会话`B`中提交上次的事务。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 6]  
       在会话`B`提交事务后，此时在会话`A`运行刚才的`SQL`。在`READ COMMITTED` 和 `REPEATABLE READ`下得到的结果就不一样了。

对于`READ COMMITTED`的事务隔离级别，总是读取行的最新版本。如果行被锁定了，则读取该行版本的最新一个快照。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 7]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 8]  
       对于 `REPEATABLE READ`，总是读取事务开始时的行数据，因此对于 `REPEATABLE READ` 隔离级别，结果:

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 9]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 10]  
       示例执行过程：

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

## 3.3 一致性锁定读 ##

默认配置下，事务的隔离级别为 `REPEATEBLE TABLE`，`InnoDB` 的 `SELECT` 操作使用一致性非锁定读。

但是某些情况下，需要对数据库读取操作进行加锁以保证数据逻辑的一致性。这要求即使对于`SELECT`的只读操作，也要加锁。`InnoDB`存储引擎对于`SELECT`语句支持两种一致性的锁定读操作：

*  SELECT … FOR UPDATE
 *  SELECT … FOR LOCK IN SHARED MODE

`SELECT ... FOR UPDATE` 对读取的记录加一个 `X` 锁，其他事务不能对已锁定的行加任何锁。

`SELECT ... FOR LOCK IN SHARED MODE` 对读取的行记录加一个`S`锁，其他事务可以向被锁定的行加S锁，但是如果加X锁，则会被阻塞。

对于一致性非锁定读，即使读取的行已被执行了 `SELECT ... FOR UPDATE`，也是可以进行读取的。

## 3.4 自增长与锁 ##

在`InnoDB`中，对每个含有自增长的计数器的表进行插入操作时，这个计数器会被初始化，执行如下的语句来得到计数器的值：

SELECT MAX(auto_inc_col) FROM t FOR UPDATE

在`InnoDB`中，自增长值的列必须是索引，同时必须是索引的第一个列。如果不是第一个列，则会抛出异常，而`MyISAM`并没有这个问题。

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

## 3.5 外键和锁 ##

外键，主要用于引用完整性的约束检查。

在`InnoDB`中，如果没有显示地对外键列加索引，那么会自动为其加一个索引，这样可以避免表锁。

对于外键值的插入和更新，首先需要查询父表中的记录，即 `SELECT` 父表。但是对于父表的 `SELECT` 操作，不是使用一致性非锁定读的方式，因为这样会发生数据不一致的问题，因此这时使用的是`SELECT ... LOCK IN SHARED MODE` 方式，即主动对父表加一个S锁。如果这时父表已经加X锁，子表上的操作会被阻塞。

# 4. 锁的算法 #

## 4.1 行锁的 3 种算法 ##

`InnoDB`有 \`3 种行锁算法，分别为：

*  Record Lock ：单个行记录上的锁
 *  Gap Lock ： 间隙锁，锁定一个范围，但不包含记录本身
 *  Next-Key Lock ：Gap Lock + Record Lock ，锁定一个范围，并且锁定记录本身。

`Recode Lock` 总是会锁住索引记录，如果 `InnoDB` 存储引擎表在建立的时候没有设置任何一个索引，那么`InnoDB`会使用隐式的主键来锁定。

`Next-Key Lock`，InnoDB 对于行的查询都是采用这种锁定算法。例如有一个索引 10，11，13和20四个值，那么该索引可能被 Next-Key Locking 的区间为：

*  (-∞, 10\]
 *  (10, 11\]
 *  (11, 13\]
 *  (13, 20\]
 *  (20, +∞\]

`Next-Key Lock`的锁定技术称为 `Next-Key Locking`。其设计的目的是为了解决 `Phantom Problem`。利用这种锁定技术，锁定的不是单个值，而是一个范围。

若事务 `T1` 已经通过`next-key locking` 锁定了如下范围：

(-10,11\]、(11,13\]

当插入新的记录`12`时，则锁定的范围变成：

(-10,11\]、(11,12\]、(12,13\]

当查询的索引含有唯一属性时，`InnoDB`会对`Next-Key Lock` 进行优化，将其降级为`Record Lock`，即仅锁住索引本身，而不是范围。

CREATE TABLE t(a INT PRIMARY KEY);
    
    INSERT INTO t SELECT 1;
    INSERT INTO t SELECT 2;
    INSERT INTO t SELECT 5;

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 13]  
       在上面的例子种，在会话`A`中首先对 `a=5` 进行X锁定。而由于 `a`是·主键且唯一的，因此锁定的仅是`5`这个值，而不是`(2,5]`这个范围，这样在会话`B`中插入值`4`而不会阻塞，可以立即返回。

Next-Key Lock 降级为 Record Lock 可以提高应用的并发性。

CREATE TABLE z(
    	a INT ,
    	b INT ,
    	PRIMARY KEY(a),
    	key(b)
    );
    
    INSERT INTO z SELECT 1,1;
    INSERT INTO z SELECT 3,1;
    INSERT INTO z SELECT 5,3;
    INSERT INTO z SELECT 7,6;
    INSERT INTO z SELECT 10,8;

若在会话`A`中执行下面的`SQL`语句:

SELECT * FROM z WHERE b=3 FOR UPDATE;

此时`SQL`通过索引列`B`进行查询，因此其使用 `Next-Key Locking` 技术加锁，并且由于有两个索引，其需要分别进行锁定。

对于聚集索引，其仅对列`a`等于`5`的索引加上`Record Lock`。

对于辅助索引，其加上的是`Next-Key Lock`，其锁定的范围是`(1,3)`，**`InnoDB`还会对辅助索引下一个键值加上`gap Lock`**，即还有一个辅助索引范围为`(3,6)`。因此，若在新会话`B`中运行下面的`SQL`，都会被阻塞。

SELECT * FROM z WHERE a = 5 LOCK IN SHARE MODE;
    
    INSERT INTO z SELECT 4,2;
    
    INSERT INTO z SELECT 6,5;

## 4.2 解决 Phantom Problem ##

默认的事务隔离级别下，即 `REPEATABLE READ` 下，`InnoDB` 采用 `Next-Key Locking` 机制来避免 `Phantom Problem`。

**Phantom Problem 指在同一事务下，连续执行两次同样的SQL语句可能导致不同的结果，第二次的SQL语句可能返回之前不存在的行**。

`Phantom Problem`示例：

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 15]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 16]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 17]

可以看到在会话`A`中相同的`SQL`得到了不同的结果，违反了事务的隔离性，即当前事务看到了其他事务的结果。

在 `REPEATED READ` 下，其采用 `Next-Key Locking`的方式加锁。

在`READ COMMITED`下，其仅采用 `Record Lock`。

# 5. 锁问题 #

## 5.1 脏读 ##

脏数据和脏页是完全不同的概念。

脏页指的是缓冲池中已经被修改的页，但是还没有刷新到磁盘中。即数据库实例内存中的页和磁盘中的页的数据不一致的，在刷新到磁盘之前已经被写入到了重做日志中。

脏数据指事务对缓冲池中行记录的修改，并且还没有(commit)，即一个事务可以读到另一个事务未提交的数据，显然违反了隔离性。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 18]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 19]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 20]  
       脏读发生的条件是事务的隔离级别为 READ UNCOMMITTED。

## 5.2 不可重复读 ##

不可重复读是指在一个事务内多次读取同一数据集合。在这个事务还没有结束时，另一个事务页访问该同一数据集合，并做了一些 DML (增删改)操作。因此，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的数据可能是不一样的。这样就导致在一个事务内两次读到的数据是不一样的，这种情况称为不可重复读。

不可重复读和脏读的区别是：**脏读是读到未提交的数据，而不可重复读读到的确是已经提交的数据，但是其违反了一致性要求**（一致性是对数据可见性的约束，保证在一个事务中的多次操作的数据中间状态对其他事务不可见的）。

不可重复读发生的条件是事务的隔离级别为 READ COMMITTED。

## 5.3 幻读（Phantom Problem） ##

幻读与不可重复读的区别是：**不可重复读，是在事务进行中，另一个事务修改了数据，事务两次查询的数据，结果条数一致，但是数据内容不一样了。 幻读，是在事务进行中，另一个事务新增了数据，事务两次查询的数据，结果条数不一致**。

幻读发生的条件是事务的隔离级别为 REPEATED READ，在`InnoDB`中，该隔离级别通过`Next Key Lock`算法解决了该问题。

# 6. 阻塞 #

阻塞是为了确保事务可以并发且正常地运行。

在`InnoDB`中，参数 `innodb_lock_wait_timeout` 用来控制等待的时间（默认`50`秒）。

# 7. 死锁 #

## 7.1 死锁的概念 ##

**死锁是指两个或两个以上的事务在执行过程中，因争夺锁资源而造成的一种相互等待的现象**。

解决死锁问题最简单的一种方法是超时。但是不够理想。

除了超时机制，当前数据库还都普遍采用 `wait-for graph`(等待图)的方式进行死锁检测。

## 7.2死锁的示例 ##

如果程序是串行的，那么不可能发生死锁。死锁只存在于并发的情况，数据库本身就是一个并发程序，所以可能发生死锁。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 21]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 22]![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 23]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 24]

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

上述情况中 `A` 等待 `B` ，`B` 在等待 `A`，称为`AB-BA`死锁。

大多数的死锁`InnoDB`可以侦测到，不需要人为进行干预。但是在上面的例子中，在会话`B`中的事务抛出死锁异常后，会话`A`中马上得到了记录为`2`的这个资源，这其实是会话`B`中的事务发生了回滚，否则会话`A`中的事务不会回滚大部分的错误异常。

# 8. 锁升级 #

锁升级是指将众多细*粒度锁*转换为较少的粗*粒度*的锁的过程。

例如，数据库可以把一个表的`1000`行锁升级为一个页锁，或者页锁升级为表锁。

InnoDB存储引擎不存在锁升级问题。因为其不是根据每个记录来产生行锁的，相反，其是根据每个事务访问的每个页对锁进行管理的，采用的是位图的方式。因此不管一个事务锁住页中一个记录还是多个记录，其开销通常是一致的。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70]: /images/20210813/2c6d892865a54e3b854d70f64dccf1f0.png
[20200601102544634.png]: /images/20210813/1935bdb9fe0e4ef38959d747a1b42d7d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 1]: /images/20210813/dd03a6e57cfc466cafc3ad6caeb55fef.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 2]: /images/20210813/583ee462594d4062b701b7aaa7494fb1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 3]: /images/20210813/38690ad7d18c43fa946d9f9b17b4fa33.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 4]: /images/20210813/9e4ea9114b81463fbbc74a969ae6e73f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 5]: /images/20210813/6301d013f3c54313ad33f74900fe125b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 6]: /images/20210813/4c79f329ed3b4cb48bbbc2da258f58ea.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 7]: /images/20210813/a4c6c1bdf94b4ad5bd5f8a522c85d88c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 8]: /images/20210813/23f36ffa6467457787581e37d7129f6f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 9]: /images/20210813/485ab96d4cdc4963ba920856569f4522.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 10]: /images/20210813/df5b88e7dbe54a8d900b6eb28b61bb84.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 11]: /images/20210813/5e07de7eee314794b3b79129aed4e580.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 12]: /images/20210813/e9f2367c2b9c4d2cab70b29f563b7cc0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 13]: /images/20210813/8fe6bce9a8684af782dedfdbf9beb2d3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 14]: /images/20210813/352c3acb61424e8f98c97617a40e7a65.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 15]: /images/20210813/3e7dbc453db14a5c9fab55d02eb8246a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 16]: /images/20210813/61bc546c89fb4dc1a3ffe1089aea6828.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 17]: /images/20210813/21ec8ee5c5fd4df7bdb067e51e934398.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 18]: /images/20210813/4241057161f6484dbc9604449311c020.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 19]: /images/20210813/1019c809cf6c45d3a2c8e4d420c57371.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 20]: /images/20210813/b87d05cdfd484cfb82e6b721a1b46621.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 21]: /images/20210813/deba39fe941e4db9a74218ae8a7d03e4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 22]: https://img-blog.csdnimg.cn/20200601130725430.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 23]: https://img-blog.csdnimg.cn/20200601130741142.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 24]: https://img-blog.csdnimg.cn/20200601130757126.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 25]: https://img-blog.csdnimg.cn/20200601130815731.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18=,size_16,color_FFFFFF,t_70