453-MySQL(MVCC和undo log)

小鱼儿 2022-09-06 15:25 163阅读 0赞

**我们一般工作在事务的中间两级隔离级别**  
2、TRANSACTION\_READ\_COMMITTED。**已提交读**。说明读取未提交的数据是不允许的。这个级别仍然允许不可重复读和虚读产生。  
3、TRANSACTION\_REPEATABLE\_READ。**可重复读**。说明事务保证能够再次读取相同的数据而不会失败，但虚读仍然会出现。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70]  
**备注：**  
事务隔离级别越高，为避免冲突所花费的性能也就越多。  
在“可重复读”级别，实际上可以解决部分的虚读问题，但是不能防止update更新产生的虚读问题，要禁止虚读产生，还是需要设置串行化隔离级别。

**InnoDB**的事务隔离级别**已提交读和可重复读**的底层实现原理：**MVCC**（多版本并发控制）–》并发的读取方式：**快照读**  
**InnoDB提供了2种读取操作**：锁定读和非锁定读  
**锁定读**就是读取的时候加锁了（S锁或者X锁）  
**非锁定读**就是读取的时候没有加锁，指的就是MVCC提供的快照读–》依赖底层的undo log回滚日志。

**事务日志**：undo log回滚日志 和 redo log重做日志  
**ACD（事务日志） I（锁和MVCC）**

**undo log回滚日志的主要作用：**  
1、事务发生错误时回滚rollback ，回滚日志（把改之前的数据存下来在回滚日志中，事务万一出错回滚了或者我们手动回滚的时候，能够把最初的数据在回滚日志中找到）  
2、提供了MVCC的非锁定读（快照读）—》undo log的原理

## undo log回滚日志 ##

**undo log**：回滚日志，保存了事务发生之前的数据的一个版本，用于事务执行时的回滚操作，同时也是实现多版本并发控制（MVCC）下读操作的关键技术。  
DB\_TRX\_ID:**事务ID**  
DB\_ROLL\_PTR:**回滚指针**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 1]  
在MVCC下，针对表的所有记录，除了我们能看到的book\_id,book\_name等存放书籍信息的一张表。  
![在这里插入图片描述][e18ff845c4bc47708af939bc7365842c.png]

它还会给这张表添加额外的字段：  
![在这里插入图片描述][e4bc46e744c44bd69a620fc403fbae2f.png]  
我们看到额外添加了3个字段，**DB\_ROW\_ID**和MVCC的关系不大，这个是你在创建表的时候，没有加主键列，InnoDB给你增加的主键列id，为了区分每一行记录，通过这个id作为主键创建索引树，在B+树的叶子节点上存放数据，因为InnoDB的数据和索引是存放在一起的，你没有设置主键，它会帮你设置主键。  
**DB\_TRX\_ID**(事务ID） （1002,1001,1000），我们在之前经常登录两个窗口，然后各输入begin；这个意思就是在两个窗口上各开启一个事务，事务开启的请求最终发到MySQL上，MySQL server为每个事务分配一个全局的，不冲突的事务ID。  
也就是说，当我这个事务1修改数据的时候，DB\_TRX\_ID放的就是事务1的ID，同一个事务对这个数据不断改来改去，这个事务ID是不会改变的。

**DB\_ROLL\_PTR**（回滚指针），我们看到，存放的是地址，这个地址表示的是一个数据的内存的位置，看起来是一个链表，这个橙色表是最后的成品，那么这个表是怎么变来的呢？

最初的是这样  
![在这里插入图片描述][74abac882066482d8b2cc85b745e7e3e.png]  
现在有一个事务来更改这条数据了。  
把book\_name给更改了。  
改成了这个  
![在这里插入图片描述][367d172abd38453f953de2fdffad027c.png]  
数据涉及到修改了，修改的数据存放在当前这个位置，那修改之前的数据存放在哪里？存放在undo log

**假设最初是** 最初给这条数据赋值的事务的ID是1000  
![在这里插入图片描述][da0b3f731f5448b8842839437832f1bf.png]  
现在要对数据进行修改。  
![在这里插入图片描述][1807f4d81ebe41bab595cf29afbd430e.png]  
对这条数据修改的事务的ID是1020  
DB\_ROLL\_PTR指针指向之前的数据（undo log，写在缓存中）  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 2]

假设现在1000这个事务又把book\_name给更改了  
这2条数据就是老数据了，都到undo log里面了  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 3]  
MVCC会给我们创建的表增加2个列，一个是事务ID，一个是指向修改前的数据的指针，修改之前的数据都是放在undo log回滚日志当中。当前数据中是哪个事务ID改的就写哪个事务ID，DB\_ROLL\_PTR指针把当前数据和旧数据串成1个链表。从当前行的DB\_ROLL\_PTR可以访问到旧数据，进行回滚是理所当然的。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 4]  
绿色数据表示当前行的最新修改的数据，是事务1002修改的，从指针DB\_ROLL\_PTR可以找到undo log找到上次修改数据的是事务1001，从事务1001的数据的DB\_ROLL\_PTR还可以找到上上次的数据是事务1000修改的。以此类推。

## 示例讲解 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 5]  
**这是原始的user表。**  
我们现在对id=7这条记录进行更改。  
在MVCC机制下，对这张表增加2列。修改当前数据的事务ID和指向undo log的指针。  
我们把id=7的age改为16。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 6]  
假如我们增加了1行新数据。  
新的数据就没有老数据。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 7]  
回滚的时候发现是空，就知道是insert的数据。  
如果我们对这条新数据进行修改了，这些数据就都跑到undo log中了  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 8]  
已提交读和可重复读这2种隔离级别下，当我们去读数据的时候，是通过共享锁，排它锁，间隙锁，MVCC的快照读实现的。

## MVCC多版本并发控制 ##

MVCC是多版本并发控制（Multi-Version Concurrency Control，简称MVCC），是MySQL中基于乐观锁理论实现隔离级别的方式，用于实现已提交读和可重复读隔离级别的实现，也经常称为多版本数据库。MVCC机制会生成一个数据请求时间点的一致性数据快照 （Snapshot)， 并用这个快照来提供一定级别 （语句级或事务级） 的一致性读取。从用户的角度来看，好象是数据库可以提供同一数据的多个版本（系统版本号和事务版本号）。

MVCC多版本并发控制中，读操作可以分为两类：  
分为  
**快照读（非锁定读）**：读的是记录的可见版本，不用加锁。如select  
**当前读**：读取的是记录的最新版本，并且当前读返回的记录。如insert，delete，update，select…lock in share  
mode/for update

MVCC：每一行记录实际上有多个版本，每个版本的记录除了数据本身之外，增加了其它字段  
DB\_TRX\_ID：记录当前事务ID  
DB\_ROLL\_PTR：指向undo log日志上数据的指针

**已提交读**：每次执行语句的时候都重新生成一次快照（Read View），每次select查询时。  
**可重复读**：同一个事务开始的时候生成一个当前事务全局性的快照（Read View），第一次select查询时

## 快照内容读取原则 ##

**1、版本未提交无法读取生成快照  
2、版本已提交，但是在快照创建后提交的，无法读取  
3、版本已提交，但是在快照创建前提交的，可以读取  
4、当前事务内自己的更新，可以读到**

## 已提交读 这个隔离机制的测试 ##

**已提交读**：解决了脏读问题。不可重复读和幻读的问题还是存在。  
![在这里插入图片描述][18faea34379040f7a2acc405d4dd3faf.png]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 9]  
脏读就是事务2读取了事务1还未提交的数据。  
事务2select  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 10]  
事务1 update  
![在这里插入图片描述][5c6968fad27e4fe2b47136953133c6c3.png]  
没有提交，事务2不能看到  
![在这里插入图片描述][4cc637393bf44d78a3bb43b5162be95b.png]  
这就是已经解决了脏读了。  
不管是已提交读还是可重复读，当我们只要select，就会产生一个数据快照，相当于给当前的数据拍个照片，以后去查询，都是查询快照上的数据。  
非锁定读是在快照上的操作。  
已提交读：每一次select都会产生一次数据快照。  
当事务1进行更改的时候，事务2又去select，重新产生数据快照了，**但是产生数据快照的前提是数据已经被事务正确commit过的**。数据有2种状态：prepare和commit  
事务2第二次select的时候，由于事务1修改数据并没有commit，又一次产生数据快照，数据快照还是链表指向的旧数据。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 11]  
**接下来测试不可重复读**  
事务1把修改的数据commit了  
![在这里插入图片描述][0212e1d808974a3592bf4c5c8042bbed.png]  
事务2现在select出来的数据就是age=16了  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 12]  
这就是不可重复读的现象。

**为什么无法解决不可重复读？**  
因为每一次select都会重新产生1次数据快照。其他事务更新后而且已commit的数据可以实时反馈到当前事务的select结果当中。

**同样的为什么会出现幻读？**  
![在这里插入图片描述][0a2345e851244f3fa308e77f8504e71a.png]  
事务2select

![在这里插入图片描述][c5f41a256cb0461296cb10231e3ae83e.png]  
然后事务1insert，然后commit提交了  
![在这里插入图片描述][0958b7b28a47417993c1b83669cc211c.png]  
然后现在事务2再查

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 13]  
出现了幻读。因为每一次select都重新产生1次快照。  
给下图的绿色框拍照。自然就幻读了。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 14]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 15]

## 可重复读测试 这个隔离机制的测试 ##

**解决了脏读问题（生成了数据快照），而且可重复读**

**为什么解决了可重复读？**  
一个事务的第一次select 产生数据快照，而且只产生1次数据快照。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 16]

事务2 第一次 select ，产生了数据快照

![在这里插入图片描述][59c6ef129adf46eba7ce6d4300ebf66d.png]  
这张照就已经写死了。事务2后面的select就不生成数据快照。  
事务1update，commit  
![在这里插入图片描述][7c5182f9b30d4498b97504df8d71b883.png]  
照片第一次已经拍了，事务1现在去修改，  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 17]  
事务2现在再去select。查的是第一次select生成的快照。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 18]  
**再举一个例子。**  
![在这里插入图片描述][b8798cdce807414abad907df46b4c8c6.png]  
刚才是事务2先第一次select了，所以产生了一次数据快照，然后事务1更改数据，事务2再查就是原来的数据快照。  
现在我们让事务1先修改数据，commit  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 19]  
现在事务2才第一次select，之前没有数据快照。  
所以可以访问到事务1更改后的数据

![在这里插入图片描述][b3f77ae6bde447d6ab248b92ed3f951b.png]  
第一次select产生数据快照，其他事务虽然修改了最新的数据，但是当前事务再select的时候，依然查看的是最初的快照数据。

**为什么部分解决了幻读？？？**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 20]  
事务2第一次select，产生了数据快照  
![在这里插入图片描述][e8df76748e254c228f3bb737018fb611.png]  
就是下面这个数据快照  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 21]  
事务1现在insert into，commit

![在这里插入图片描述][7a8942ee0754414d8b1fe5a764dcfcea.png]  
事务2再select，查看的是最初的数据快照。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 22]  
已经解决了幻读。  
但是我们说，只是部分解决了幻读  
那是因为  
我们现在在事务2update  
但是update，insert，delete，做的是当前读，读的是最新的数据！  
更新的是最新的数据  
假设事务1的ID是1000，事务2的ID是2000  
事务1第一次insert的数据的事务ID就是1000  
现在事务2执行update，修改事务1insert的数据，当前最新数据的事务ID是2000

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 23]  
**当前事务是可以看见自己事务修改，更新的数据的。**  
现在事务2update修改，是当前读。  
![在这里插入图片描述][9359286a2b894429bf0bf0764e0a62bc.png]  
如果事务2再去select的时候，它不仅可以看到数据快照，还可以看到自己修改的数据

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70]: /images/20220829/25eadce3b6454cce89dff25a1832b96b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 1]: /images/20220829/597609a152854c698e0c27701513e470.png
[e18ff845c4bc47708af939bc7365842c.png]: /images/20220829/ee41dc7876e74216bbea237c33125797.png
[e4bc46e744c44bd69a620fc403fbae2f.png]: /images/20220829/85fe28a97c73479cbbb468e9a1b68992.png
[74abac882066482d8b2cc85b745e7e3e.png]: /images/20220829/a33a2e504b20408fbceb8ae9c9909b7a.png
[367d172abd38453f953de2fdffad027c.png]: /images/20220829/f807753e1ba44d9aac8d608ce805bf0a.png
[da0b3f731f5448b8842839437832f1bf.png]: /images/20220829/30cb684a0bea4d3181afc42c52c7e242.png
[1807f4d81ebe41bab595cf29afbd430e.png]: /images/20220829/b64a732d85184cdeb9617868a72c070f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 2]: /images/20220829/f8d6a6517b97427091e9623f897efd5d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 3]: /images/20220829/43d470ea845b48aa894895bdef01fb5b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 4]: /images/20220829/011675b9baf348038d2e275225a5e7b8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 5]: /images/20220829/b8863e1188b042a0bd5314c3cacb46e0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 6]: /images/20220829/ecb07218558c4e45b1620e2b797ff74b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 7]: /images/20220829/b6959f815d8143819fceb594e6464f6b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 8]: /images/20220829/88516ceacbc34dc4ad38a9df9e1ec02a.png
[18faea34379040f7a2acc405d4dd3faf.png]: /images/20220829/cc5037f101d14028a31ae0f016ff54cb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 9]: /images/20220829/87fce66a76d04d0fbceb060b6b996732.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 10]: /images/20220829/c4e5d062486c4724951d5bff42c14899.png
[5c6968fad27e4fe2b47136953133c6c3.png]: /images/20220829/f3373c2d32ba4cb1919e7eb03f4b00ff.png
[4cc637393bf44d78a3bb43b5162be95b.png]: /images/20220829/a726df6ae9d644179cb0da1e0379764c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 11]: /images/20220829/df79a1dc1f3b47fb8c3bb846b5c0d9a7.png
[0212e1d808974a3592bf4c5c8042bbed.png]: /images/20220829/c64e797a54f34a48a415ee36ef4ff04d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 12]: /images/20220829/ae159aacf8a249cd898fa70930da5d6e.png
[0a2345e851244f3fa308e77f8504e71a.png]: /images/20220829/46239ee961a949c38700a43c935c73e3.png
[c5f41a256cb0461296cb10231e3ae83e.png]: /images/20220829/cdc5ce2666a940dea7e70fc937e1dd9e.png
[0958b7b28a47417993c1b83669cc211c.png]: /images/20220829/29603b86a5b34a9d960aff3238baad2d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 13]: /images/20220829/6709167e3a2c4deea277f0a3302f5a65.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 14]: /images/20220829/7aaa389cefe746e2a1270e5e3c39797d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 15]: /images/20220829/d7cf004a27e34b11a11769838c1090a7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 16]: /images/20220829/bf685211385145fca2f59999781314df.png
[59c6ef129adf46eba7ce6d4300ebf66d.png]: /images/20220829/132c61f76b6e4359b94607e3f9d0821d.png
[7c5182f9b30d4498b97504df8d71b883.png]: /images/20220829/28c5f05046da4621bb7387e1b7c7be34.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 17]: /images/20220829/69a65adbfe184f3cae030a30721a6030.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 18]: /images/20220829/c23f9be8df564667b132c7a2bb409678.png
[b8798cdce807414abad907df46b4c8c6.png]: /images/20220829/0ca6c382e22645d282a7961f3e857615.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 19]: /images/20220829/127f1e1ff1854d8fb76072fec1a3c361.png
[b3f77ae6bde447d6ab248b92ed3f951b.png]: /images/20220829/a104a67bdc4a4e3db406d5854283f025.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 20]: /images/20220829/991c82d2b17f41358ebad855deca5514.png
[e8df76748e254c228f3bb737018fb611.png]: /images/20220829/7356806b8f7441b3b08dc3206446782b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 21]: /images/20220829/5d7af5bb76ab40929252a73cc318af55.png
[7a8942ee0754414d8b1fe5a764dcfcea.png]: /images/20220829/f8989208dd744439b4632ca8ec982845.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 22]: /images/20220829/e6251114a0b04ae593986f5c49528c98.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 23]: /images/20220829/5afc1fead7db4449bcc13aa6bb14dfe6.png
[9359286a2b894429bf0bf0764e0a62bc.png]: /images/20220829/6040379fa2b94d86a961a1f74bfa80a3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 24]: /images/20220829/7e20cdcc695d4d4fbe33a4ae87db2dc5.png