innodb存储引擎锁的实现(一)

爱被打了一巴掌 2022-05-19 09:59 261阅读 0赞

### **| 概述** ###

通常，我们在95%以上的MySQL使用场景中，从一定程度上来讲，就是在使用InnoDB存储引擎，很多时候我们选择使用InnoDB存储引擎的原因，就是因为它支持高并发，而高并发的实现很大程度上得益于细粒度的锁实现（行级锁），不仅如此，MySQL 还支持更多灵活多变的锁类型，例如：按照锁类型可分为共享锁(S锁)和排它锁(X锁)，按照锁范围可分为记录锁(record lock)、间隙锁(gap lock)、next-key lock。以及一些其他特殊用途的锁。这些锁在不同的隔离级别下存在着不同的表现形式。尤其在RR隔离级别下锁的类型最为丰富、灵活多变。下面我们将为大家一一介绍这些锁的含义和用途。

PS：由于本文侧重点在于介绍锁类型，所以下文中的示例统一使用RR隔离级别进行演示，其他隔离级别下的锁表现形式如有兴趣请自行研究。

### **| innodb存储引擎行锁的算法** ###

数据库对锁的使用是为了支持对共享资源进行并发的访问，提供数据的完整性和一致性。innodb存储引擎提供了表锁、行锁和意向锁用来实现事物在不同粒度上进行上锁，从而提高数据库的并发访问，并且保证数据的完整性和一致性。

**innodb存储引擎的锁类型**

innodb存储引擎是通过给索引上的索引项加锁来实现行锁，这种特点也就意味着，只要通过索引条件检索数据，innodb才会使用行级锁，否则会使用表锁。innodb存储引擎有以下锁类型：

*  1.共享锁和排他锁（Shared and Exclusive Locks）
 *  2.意向锁（Intention Locks）
 *  3.记录锁（Record Locks）
 *  4.间隙锁（Gap Locks）
 *  5.Next-Key Locks
 *  6.插入意向锁（Insert Intention Locks）
 *  7.自增锁（AUTO-INC Locks）
 *  8.空间索引谓词锁（Predicate Locks for Spatial Indexes）

**（1）共享锁和排他锁（Shared and Exclusive Locks）**

*  innodb实现标准行级锁，其中有两种类型的锁，共享锁（S）和独占锁（X）。
    
     *  1.共享锁，允许一个事务去读一行，阻止其他事务获得相同数据集的排它锁。
     *  2.排它锁，允许获取排他锁的事务更新数据，阻止其他事务取得相同的数据集的共享读锁和排他锁。
 *  如果事务T1持有一行记录的共享锁，那么另一个不同的事务T2对该行记录的锁定如下：
    
     *  1.如果事务T2对该行的请求是一个S锁，那么事务T1和事务T2可以共同对该行记录持有同一把S锁。
     *  2.如果事务T2对该行的请求是一个X锁，那么事务T2不可能马上获得对该行记录的X锁，必须要等到事务T1将该记录的S锁释放，才可以对该行记录持有X锁。
     *  3.如果事务T1持有第 r 行的独占（X）锁，那么对于事务T2对该行记录的任何一种请求的锁都不能立即授予。相反，事务T2必须要等到事务T1释放在r 行上的锁。

**（2）意向锁（Intention Locks）**

innodb存储引擎支持多种粒度锁，允许行锁和表锁共存。为了在多个粒度级别上进行锁定，innodb存储引擎使用意向锁来实现。意向锁是表级锁，它先指明了该事物是那种类型的锁（共享锁或者独占锁），然后去锁定表中某行记录。（我们可以在后面的Gap lock 和 Next-Key Locks 的演示中MySQL 8.0 的information\_schema.data\_locks 表中显示的信息看到）

有两种类型的意向锁：

*  1.意向共享锁（IS），表明事务在一个表中的单个行上设置共享锁。
 *  2.意向独占锁（IX），表明事务在表中的某行设置独占锁。   
    例如，SELECT … LOCK IN SHARE MODE 是IS，而 SELECT … FOR UPDATE 是IX锁。
 *  意向锁的添加方式：
    
     *  1.在一个事务对一张表的某行添加S锁之前，它必须对该表获取一个IS锁或者优先级更高的锁。
     *  2.在一个事务对一张表的某行添加X锁之前，它必须对该表获取一个IX锁。
 *  表级锁类型兼容性如下图所示：

![70][]

*  如果与现有锁相兼容，则授予事务请求的锁，但如果它与之冲突，则不会，并且该事务一直等待直到冲突的现有锁被释放。如果所请求的锁与持有的锁冲突是不可能被授予，因为这将会导致死锁，并且返回错误。
 *  意向锁不会阻塞任何请求，除非将这个表锁住，例如，LOCK TABLE …. WRITE。意向锁的主要目的是显示某人正在锁定一行，或者在锁定表中的一行数据。

（3）记录锁（Record Locks）

Record Lock总是会去锁定主键、非空的唯一性索引对应的索引记录，如果在建innodb表时并没有创建任何索引，innodb会对6字节的rowid的主键来进行锁定。Read-Uncommited/RC级别都是使用该方式来进行加锁。

Record Lock的主要目的：行锁可以防止不同事务版本的数据修改提交时造成数据冲突的情况。

admin@localhost : test 10:53:27> select * from test;
    +------+------+
    | id  | xid  |
    +------+------+
    |    1 |    2 |
    |    3 |    3 |
    +------+------+
    2 rows in set (0.00 sec)
    admin@localhost : test 10:53:45> show index from test;
    Empty set (0.01 sec)
    admin@localhost : test 10:54:05> show create table test;
    +-------+---------------------------------------------------------------------------------------------------------------------------------------+
    | Table | Create Table                                                                                                                          |
    +-------+---------------------------------------------------------------------------------------------------------------------------------------+
    | test  | CREATE TABLE `test` (
    `id` int(11) DEFAULT NULL,
    `xid` int(11) DEFAULT NULL
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin |
    +-------+---------------------------------------------------------------------------------------------------------------------------------------+
    1 row in set (0.00 sec)

下面我们开启2个会话session A 、session B 、session C进行测试

![70 1][]

可以通过INFORMATION\_SCHEMA中的innodb\_lock\_waits、innodb\_locks、innodb\_trx查看到锁的详细信息

admin@localhost : test 11:10:26> select * from information_schema.innodb_lock_waits;
    +-------------------+-------------------+-----------------+------------------+
    | requesting_trx_id | requested_lock_id | blocking_trx_id | blocking_lock_id |
    +-------------------+-------------------+-----------------+------------------+
    | 17660049          | 17660049:589:3:4  | 17660047        | 17660047:589:3:4 |
    +-------------------+-------------------+-----------------+------------------+
    1 row in set, 1 warning (0.02 sec)
    Warning (Code 1681): 'INFORMATION_SCHEMA.INNODB_LOCK_WAITS' is deprecated and will be removed in a future release.
    admin@localhost : test 11:10:35> select * from information_schema.innodb_locks;
    +------------------+-------------+-----------+-----------+---------------+-----------------+------------+-----------+----------+----------------+
    | lock_id          | lock_trx_id | lock_mode | lock_type | lock_table    | lock_index      | lock_space | lock_page | lock_rec | lock_data      |
    +------------------+-------------+-----------+-----------+---------------+-----------------+------------+-----------+----------+----------------+
    | 17660049:589:3:4 | 17660049    | X        | RECORD    | `test`.`test` | GEN_CLUST_INDEX |        589 |        3 |        4 | 0x000000000400 |
    | 17660047:589:3:4 | 17660047    | X        | RECORD    | `test`.`test` | GEN_CLUST_INDEX |        589 |        3 |        4 | 0x000000000400 |
    +------------------+-------------+-----------+-----------+---------------+-----------------+------------+-----------+----------+----------------+
    2 rows in set, 1 warning (0.00 sec)
    admin@localhost : test 11:11:31> select * from information_schema.innodb_trx\G
    *************************** 1. row ***************************
                    trx_id: 17660049
                trx_state: LOCK WAIT
              trx_started: 2018-05-24 11:10:33
    trx_requested_lock_id: 17660049:589:3:4
          trx_wait_started: 2018-05-24 11:10:33
                trx_weight: 3
      trx_mysql_thread_id: 15
                trx_query: update test set xid=5 where id=3
      trx_operation_state: fetching rows
        trx_tables_in_use: 1
        trx_tables_locked: 1
          trx_lock_structs: 3
    trx_lock_memory_bytes: 1136
          trx_rows_locked: 2
        trx_rows_modified: 0
    trx_concurrency_tickets: 0
      trx_isolation_level: READ COMMITTED
        trx_unique_checks: 1
    trx_foreign_key_checks: 1
    trx_last_foreign_key_error: NULL
    trx_adaptive_hash_latched: 0
    trx_adaptive_hash_timeout: 0
          trx_is_read_only: 0
    trx_autocommit_non_locking: 0

从information\_schema.innodb\_locks可以看出session A的事务17660047 与 session C 的事务 17660049 都是对聚集索引上的id=3记录是上排它锁，并且session C 的事务 17660049 在等待session A的事务17660047 的X锁对 id = 3记录的释放。

（4）间隙锁（Gap Locks）

*  Gap Lock：间隙锁只存在于RR隔离级别下的辅助索引中，只锁定一个范围，但不包含记录本身。如果只锁定一个范围，那这个范围是怎样的？
 *  Gap Lock的主要目的：间隙锁避免了别的事务插入数据，从而避免了不可重复读现象。
 *  Gap Lock的特点：
    
     *  一个间隙锁可能间隔一个索引值、多个索引值或者是无穷
     *  间隙锁是为了平衡性能和并发的一部分，并且间隙锁只能在RR隔离级别下使用
     *  对于使用唯一索引查找数据，是不需要使用间隙锁，但是并不包含查询条件中只包含多列中的某些列，唯一索引在这样的情况下，会使用间隙锁来锁定。
     *  不同的事务可以在一个间隙锁中持有冲突的锁。如果事务A在一个间隙锁中持有的是共享的间隙锁（gap S-lock），而事务B持有事务A在相同间隙的独占间隙锁（gap X-lock）。该类型的锁冲突间隙锁是允许的，如果a记录被从索引上删除，不同事务在该记录上的间隙锁将被合并。
     *  innodb存储引擎的间隙锁范围是完全禁止操作的，这将意味着其他事务无法对间隙锁范围进行插入操作。间隙锁不会阻止不同的事务去获取同样的间隙锁范围，因此间隙锁 gap X-lock 和 gap S-lock 的效果是一样的。
     *  间隙锁可以被显式的禁用。将事务的隔离级别设置为 READ COMMITTED 或者开启 innodb\_locks\_unsafe\_for\_binlog=ON （已经被弃用）。在这样的情况下，在查询和索引扫描中禁用间隙锁，并且只适用于外键约束和主键检查。
     *  在使用READ COMMITTED隔离级别或者开启 innodb\_locks\_unsafe\_for\_binlog=ON 都可以显式的禁用间隙锁。开启“semi-consistent” 半一致行读取后，MySQL 会过滤掉不匹配的行，并且释放不匹配的行的锁，并且将过滤后数据返回到存储引擎层去更新。
 *  测试步骤   
    在RR隔离级别下，创建一张只有辅助索引的t3表，并且对辅助索引的一个范围使用 for update 查询，插入包含在范围中的值，然后分别对范围的上确界和下确界进行update操作。

admin@localhost : test 03:55:34> set session transaction_isolation='REPEATABLE-READ' ;
    Query OK, 0 rows affected (0.00 sec)
    admin@localhost : test 03:29:44> show variables like '%lation';
    +---------------+-----------------+
    | Variable_name | Value          |
    +---------------+-----------------+
    | transaction_isolation | REPEATABLE-READ |
    +---------------+-----------------+
    1 row in set (0.01 sec)
    root@localhost : test1 12:12:40> select * from t3;
    +------+------+
    | id | xid |
    +------+------+
    | 1 | 1 |
    | 2 | 1 |
    | 4 | 3 |
    | 7 | 7 |
    | 10 | 9 |
    +------+------+
    5 rows in set (0.00 sec)
    root@localhost : test1 12:08:24> show index from t3;
    +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
    | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
    +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
    | t3 | 1 | xid | 1 | xid | A | 3 | NULL | NULL | YES | BTREE | | |
    +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
    1 row in set (0.00 sec)

![70 2][]

接下来使用mysql 8.0 中的performance\_schema.data\_locks 来辅助我们查看这2个事务具体锁的那条记录，和锁的模式等相关信息。

root@localhost : (none) 04:48:29> select * from performance_schema.data_locks;
    +--------+----------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+-----------------+-----------------------+-----------+-----------+-------------+-------------------+
    | ENGINE | ENGINE_LOCK_ID | ENGINE_TRANSACTION_ID | THREAD_ID | EVENT_ID | OBJECT_SCHEMA | OBJECT_NAME | PARTITION_NAME | SUBPARTITION_NAME | INDEX_NAME | OBJECT_INSTANCE_BEGIN | LOCK_TYPE | LOCK_MODE | LOCK_STATUS | LOCK_DATA |
    +--------+----------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+-----------------+-----------------------+-----------+-----------+-------------+-------------------+
    | INNODB | 1609:1059 | 1609 | 64 | 63 | test | t | NULL | NULL | NULL | 140152030668888 | TABLE | IX | GRANTED | NULL |
    | INNODB | 1609:2:5:4 | 1609 | 64 | 63 | test | t | NULL | NULL | xid | 140152030665848 | RECORD | X,GAP | WAITING | 3, 0x000000000202 |
    | INNODB | 1608:1059 | 1608 | 63 | 88 | test | t | NULL | NULL | NULL | 140152030662936 | TABLE | IX | GRANTED | NULL |
    | INNODB | 1608:2:5:4 | 1608 | 63 | 88 | test | t | NULL | NULL | xid | 140152030659896 | RECORD | X | GRANTED | 3, 0x000000000202 |
    | INNODB | 1608:2:4:4 | 1608 | 63 | 88 | test | t | NULL | NULL | GEN_CLUST_INDEX | 140152030660240 | RECORD | X | GRANTED | 0x000000000202 |
    | INNODB | 1608:2:5:5 | 1608 | 63 | 88 | test | t | NULL | NULL | xid | 140152030660584 | RECORD | X,GAP | GRANTED | 7, 0x000000000203 |
    +--------+----------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+-----------------+-----------------------+-----------+-----------+-------------+-------------------+
    6 rows in set (0.00 sec)

![70 3][]

事务A 造成的锁

1、  | INNODB | 1608:1059 | 1608 | 63 | 88 | test | t | NULL | NULL | NULL | 140152030662936 | TABLE | IX | GRANTED | NULL |
    2、 | INNODB | 1608:2:5:4 | 1608 | 63 | 88 | test | t | NULL | NULL | xid | 140152030659896 | RECORD | X | GRANTED | 3, 0x000000000202 
    事务A对test库的t表上的辅助索引xid  对xid=3记录加 RECORD 锁，0x000000000202 表示其对应的6字节的rowid的位置指针。
    3、| INNODB | 1608:2:4:4 | 1608 | 63 | 88 | test | t | NULL | NULL | GEN_CLUST_INDEX | 140152030660240 | RECORD | X | GRANTED | 0x000000000202 |
    由于test库的t表只有一个非唯一的辅助索引xid，会使用6字节的rowid来作为聚集索引，事务A造成的锁会对 辅助索引xid=3 记录对应的聚集索引也加X锁，相当于将辅助索引xid=3的整条行记录都上X锁
    4、| INNODB | 1608:2:5:5 | 1608 | 63 | 88 | test | t | NULL | NULL | xid | 140152030660584 | RECORD | X,GAP | GRANTED | 7, 0x000000000203 |
    记录xid=7 上虽然添加的锁为X，GAP锁，但是并没有对辅助索引xid=7对应的聚集索引添加X锁，所以辅助索引xid=7这条记录并没有上X锁，实际上只是用来表示与前一行记录在 (3,7)区间构成间隙锁。

事务B造成的锁

| INNODB | 1609:1059 | 1609 | 64 | 63 | test | t | NULL | NULL | NULL | 140152030668888 | TABLE | IX | GRANTED | NULL |
    | INNODB | 1609:2:5:4 | 1609 | 64 | 63 | test | t | NULL | NULL | xid | 140152030665848 | RECORD | X,GAP | WAITING | 3, 0x000000000202 |
    事务B在事务A已经持有锁的情况下，进行插入(id，xid) ====>(1,2) 发现(1,3)存在间隙锁。无法进行插入操作。

**（5）Next-Key Lock**

Next-Key Lock 是结合了Gap Lock和Record Lock的合并，其设计目的主要是为解决RR级别下的幻读问题。该锁定方式相对于Gap Lock和Record Lock是带闭合区间的范围锁定。

以下介绍其特点：

*  Innodb存储引擎使用Next-Key Locks 只在 REPEATABLE READ 隔离级别下。
 *  当进行查询或者索引扫描时，innodb存储引擎以行锁的方式进行锁定，它会将符合条件的索引记录使用S锁或者X锁。因此，行级锁实际上就是对索引记录上锁。Next-Key Locks会影响 gap锁 的上一个索引记录，也就是Next-Key Locks是由索引记录锁加上gap 锁组成。如果一个会话，在索引记录R上有一个共享或者独占锁，在索引记录R与上一个索引记录之间的间隙，另一个会话不可能插入一个新的索引记录。
 *  Next-Key Locks在某些情况下可以锁住索引记录的最大值和大于最大值的范围，大于最大索引记录的范围称为 "supremum pseudo-record"伪记录。   
    注：官方文档并没有介绍对Next-Key Lock介绍太多，所以我们通过以下场景来对Next-Key Lock的特点进行说明。
 *  场景一：RR隔离级别下对一张只有主键的表进行操作
    
     *  主键只是由一列构成

root@localhost : test1 07:58:18> select * from t1;
    +----+------+
    | id | xid |
    +----+------+
    | 1 | 1 |
    | 2 | 1 |
    | 4 | 3 |
    | 7 | 7 |
    | 10 | 9 |
    +----+------+
    5 rows in set (0.00 sec)
    root@localhost : test1 07:58:10> show index from t1;
    +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
    | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
    +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
    | t2 | 0 | PRIMARY | 1 | id | A | 4 | NULL | NULL | | BTREE | | |
    +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
    1 row in set (0.00 sec)

![70 4][]

事务A造成的锁

| INNODB | 1611:1060 | 1611 | 63 | 94 | test | t1 | NULL | NULL | NULL | 140152030662936 | TABLE | IX | GRANTED | NULL |
    | INNODB | 1611:3:4:4 | 1611 | 63 | 94 | test | t1 | NULL | NULL | PRIMARY | 140152030659896 | RECORD | X | GRANTED | 4 |
    由于我们显示的定义了主键可以看到这里LOCK_DATA=4就是这个表内建的rowid ，说明聚集索引上的id=4的行记录直接被加了X锁，也并没有用到GAP锁。

该场景与GAP锁的场景相比较可以发现，在RR隔离级别下当过滤条件的列是主键或者唯一索引的情况下，因为该列值都是唯一值，innodb存储引擎会对Next-Key Lock进行优化，Next-Key Lock会降级成为Record Lock。换句话说gap锁只存在于RR隔离级别下的辅助索引中，主键和唯一索引由于本身具有唯一约束，不需要gap锁，只有record lock

*  如果主键由多列构成，但是只使用其中的一列进行查询呢？

root@localhost : test 05:03:13> select * from t3;
    +----+-----+------+
    | id | xid | name |
    +----+-----+------+
    | 1 | 1 | a |
    | 2 | 1 | b |
    | 4 | 3 | c |
    | 7 | 7 | d |
    | 10 | 9 | e |
    +----+-----+------+
    5 rows in set (0.00 sec)
    root@localhost : test 05:03:18> show index from t3;
    +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+
    | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Visible |
    +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+
    | t3 | 0 | PRIMARY | 1 | id | A | 5 | NULL | NULL | | BTREE | | | YES |
    | t3 | 0 | PRIMARY | 2 | xid | A | 5 | NULL | NULL | | BTREE | | | YES |
    +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+
    2 rows in set (0.29 sec)

![70 5][]

我们看到了什么？可以发现当主键由多列构成时，我们只使用主键列中的一列进行查询时，依然使用到了Next\_Key Lock ，为什么这样？

我们都知道主键的键值是唯一的，但是我们这里定义的主键是primary key(id,xid) 表示的是(id,xid) 组成的键值是唯一的，并不能保证id或者xid的键值是唯一的，所以这里依然使用Next\_Key Lock 来进行加锁并没有降级使用Record lock 来进行加锁。

*  那当使用主键所有列进行查询时是什么样子的？

![70 6][]

可以看到当我们使用主键的所有列进行查询时Next\_Key Lock 降级为Record Lock 。

*  场景二：RR隔离级别下对一张只有非唯一索引的表做操作   
    在RR隔离级别下，当表中只有一个索引并且为非唯一索引条件上进行等值当前读或者范围当前读时，其加锁是怎样的？

admin@localhost : test 03:55:34> set session transaction_isolation='REPEATABLE-READ' ;
    Query OK, 0 rows affected (0.00 sec)
    admin@localhost : test 03:29:44> show variables like '%lation';
    +---------------+-----------------+
    | Variable_name | Value          |
    +---------------+-----------------+
    | transaction_isolation| REPEATABLE-READ |
    +---------------+-----------------+
    1 row in set (0.01 sec)
    root@localhost : test1 12:12:40> select * from t;
    +------+------+
    | id | xid |
    +------+------+
    | 1 | 1 |
    | 2 | 1 |
    | 4 | 3 |
    | 7 | 7 |
    | 10 | 9 |
    +------+------+
    5 rows in set (0.00 sec)
    root@localhost : test1 12:08:24> show index from t;
    +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
    | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
    +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
    | t3 | 1 | xid | 1 | xid | A | 3 | NULL | NULL | YES | BTREE | | |
    +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
    1 row in set (0.00 sec)

*  等值当前读

![70 7][]

root@localhost : (none) 06:51:25> select * from performance_schema.data_locks;
    +--------+----------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+-----------------+-----------------------+-----------+-----------+-------------+-------------------+
    | ENGINE | ENGINE_LOCK_ID | ENGINE_TRANSACTION_ID | THREAD_ID | EVENT_ID | OBJECT_SCHEMA | OBJECT_NAME | PARTITION_NAME | SUBPARTITION_NAME | INDEX_NAME | OBJECT_INSTANCE_BEGIN | LOCK_TYPE | LOCK_MODE | LOCK_STATUS | LOCK_DATA |
    +--------+----------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+-----------------+-----------------------+-----------+-----------+-------------+-------------------+
    | INNODB | 1622:1059 | 1622 | 64 | 86 | test | t | NULL | NULL | NULL | 140152030668888 | TABLE | IX | GRANTED | NULL |
    | INNODB | 1622:2:5:5 | 1622 | 64 | 86 | test | t | NULL | NULL | xid | 140152030665848 | RECORD | X,GAP | WAITING | 7, 0x000000000203 |
    | INNODB | 1621:1059 | 1621 | 63 | 111 | test | t | NULL | NULL | NULL | 140152030662936 | TABLE | IX | GRANTED | NULL |
    | INNODB | 1621:2:5:4 | 1621 | 63 | 111 | test | t | NULL | NULL | xid | 140152030659896 | RECORD | X | GRANTED | 3, 0x000000000202 |
    | INNODB | 1621:2:4:4 | 1621 | 63 | 111 | test | t | NULL | NULL | GEN_CLUST_INDEX | 140152030660240 | RECORD | X | GRANTED | 0x000000000202 |
    | INNODB | 1621:2:5:5 | 1621 | 63 | 111 | test | t | NULL | NULL | xid | 140152030660584 | RECORD | X,GAP | GRANTED | 7, 0x000000000203 |
    +--------+----------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+-----------------+-----------------------+-----------+-----------+-------------+-------------------+
    6 rows in set (0.00 sec)

事务A造成的锁

| INNODB | 1621:1059 | 1621 | 63 | 111 | test | t | NULL | NULL | NULL | 140152030662936 | TABLE | IX | GRANTED | NULL |
    | INNODB | 1621:2:5:4 | 1621 | 63 | 111 | test | t | NULL | NULL | xid | 140152030659896 | RECORD | X | GRANTED | 3, 0x000000000202 |
    | INNODB | 1621:2:4:4 | 1621 | 63 | 111 | test | t | NULL | NULL | GEN_CLUST_INDEX | 140152030660240 | RECORD | X | GRANTED | 0x000000000202 |
    | INNODB | 1621:2:5:5 | 1621 | 63 | 111 | test | t | NULL | NULL | xid | 140152030660584 | RECORD | X,GAP | GRANTED | 7, 0x000000000203 |

事务B造成的锁

| INNODB | 1622:1059 | 1622 | 64 | 86 | test | t | NULL | NULL | NULL | 140152030668888 | TABLE | IX | GRANTED | NULL |
    | INNODB | 1622:2:5:5 | 1622 | 64 | 86 | test | t | NULL | NULL | xid | 140152030665848 | RECORD | X,GAP | WAITING | 7, 0x000000000203 |
    由于事务A在辅助索引记录 (3,7)之间是间隙锁，而事务B插入的数据(id,xid) ===>(5,5) 中的xid=5在(3,7) 间隙锁范围中，所以才会显示LOCK_MODE =X,GAP   LOCK_STATUS=WAITING      LOCK_DATA = 7, 0x000000000203   会等待事务A将锁释放直至超时。

事务C说明事务A造成的间隙锁实际上并没有将辅助索引记录xid=7也锁住，不包含记录xid=7。

事务A的加锁方式下图所示：

![70 8][]

*  范围当前读

![70 9][]

root@localhost : (none) 07:08:05> select * from performance_schema.data_locks;
    +--------+----------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+-----------------+-----------------------+-----------+-----------+-------------+-------------------+
    | ENGINE | ENGINE_LOCK_ID | ENGINE_TRANSACTION_ID | THREAD_ID | EVENT_ID | OBJECT_SCHEMA | OBJECT_NAME | PARTITION_NAME | SUBPARTITION_NAME | INDEX_NAME | OBJECT_INSTANCE_BEGIN | LOCK_TYPE | LOCK_MODE | LOCK_STATUS | LOCK_DATA |
    +--------+----------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+-----------------+-----------------------+-----------+-----------+-------------+-------------------+
    | INNODB | 1624:1059 | 1624 | 64 | 93 | test | t | NULL | NULL | NULL | 140152030668888 | TABLE | IX | GRANTED | NULL |
    | INNODB | 1624:2:5:5 | 1624 | 64 | 93 | test | t | NULL | NULL | xid | 140152030665848 | RECORD | X | WAITING | 7, 0x000000000203 |
    | INNODB | 1623:1059 | 1623 | 63 | 115 | test | t | NULL | NULL | NULL | 140152030662936 | TABLE | IX | GRANTED | NULL |
    | INNODB | 1623:2:5:4 | 1623 | 63 | 115 | test | t | NULL | NULL | xid | 140152030659896 | RECORD | X | GRANTED | 3, 0x000000000202 |
    | INNODB | 1623:2:5:5 | 1623 | 63 | 115 | test | t | NULL | NULL | xid | 140152030659896 | RECORD | X | GRANTED | 7, 0x000000000203 |
    | INNODB | 1623:2:4:4 | 1623 | 63 | 115 | test | t | NULL | NULL | GEN_CLUST_INDEX | 140152030660240 | RECORD | X | GRANTED | 0x000000000202 |
    +--------+----------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+-----------------+-----------------------+-----------+-----------+-------------+-------------------+
    6 rows in set (0.00 sec)

事务A 造成的锁

1、| INNODB | 1623:1059 | 1623 | 63 | 115 | test | t | NULL | NULL | NULL | 140152030662936 | TABLE | IX | GRANTED | NULL |
    2、| INNODB | 1623:2:5:4 | 1623 | 63 | 115 | test | t | NULL | NULL | xid | 140152030659896 | RECORD | X | GRANTED | 3, 0x000000000202 |
    3、| INNODB | 1623:2:5:5 | 1623 | 63 | 115 | test | t | NULL | NULL | xid | 140152030659896 | RECORD | X | GRANTED | 7, 0x000000000203 |
    与 select * from t where xid=3 for update; 当前读相比通过mysql 8.0的performance_schema.data_locks表可以看到辅助索引记录xid=7 的LOCK_MODE =X,GAP  其不会锁定辅助索引xid=7记录，而范围当前读会将其锁住
    4、| INNODB | 1623:2:4:4 | 1623 | 63 | 115 | test | t | NULL | NULL | GEN_CLUST_INDEX | 140152030660240 | RECORD | X | GRANTED | 0x000000000202 |
    。

![70 10][]

*  如果是select \* from t where xid>1 and xid<=7 for update; 又是怎么样的呢？

![70 11][]

root@localhost : (none) 09:49:17> select * from performance_schema.data_locks;
    +--------+----------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+-----------------+-----------------------+-----------+-----------+-------------+-------------------+
    | ENGINE | ENGINE_LOCK_ID | ENGINE_TRANSACTION_ID | THREAD_ID | EVENT_ID | OBJECT_SCHEMA | OBJECT_NAME | PARTITION_NAME | SUBPARTITION_NAME | INDEX_NAME | OBJECT_INSTANCE_BEGIN | LOCK_TYPE | LOCK_MODE | LOCK_STATUS | LOCK_DATA |
    +--------+----------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+-----------------+-----------------------+-----------+-----------+-------------+-------------------+
    | INNODB | 2061:1059 | 2061 | 64 | 24 | test | t | NULL | NULL | NULL | 139846618228824 | TABLE | IX | GRANTED | NULL |
    | INNODB | 2061:2:5:4 | 2061 | 64 | 24 | test | t | NULL | NULL | xid | 139846618225784 | RECORD | X | GRANTED | 3, 0x000000000202 |
    | INNODB | 2061:2:5:5 | 2061 | 64 | 24 | test | t | NULL | NULL | xid | 139846618225784 | RECORD | X | GRANTED | 7, 0x000000000203 |
    | INNODB | 2061:2:5:6 | 2061 | 64 | 24 | test | t | NULL | NULL | xid | 139846618225784 | RECORD | X | GRANTED | 9, 0x000000000205 |
    | INNODB | 2061:2:4:4 | 2061 | 64 | 24 | test | t | NULL | NULL | GEN_CLUST_INDEX | 139846618226128 | RECORD | X | GRANTED | 0x000000000202 |
    | INNODB | 2061:2:4:5 | 2061 | 64 | 24 | test | t | NULL | NULL | GEN_CLUST_INDEX | 139846618226128 | RECORD | X | GRANTED | 0x000000000203 |
    +--------+----------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+-----------------+-----------------------+-----------+-----------+-------------+-------------------+
    6 rows in set (0.62 sec)

其加锁下图所示：

![70 12][]

说明：由于该表没有主键只有一个非唯一的辅助索引key（xid ），使用6字节rowid做聚集索引。

![70 13][]

*  如果是select \* from t where xid>3 for update; 又是怎么样的呢？

![70 14][]

root@localhost : test 03:25:06> select * from performance_schema.data_locks;
    +--------+----------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+-----------------+-----------------------+-----------+-----------+-------------+------------------------+
    | ENGINE | ENGINE_LOCK_ID | ENGINE_TRANSACTION_ID | THREAD_ID | EVENT_ID | OBJECT_SCHEMA | OBJECT_NAME | PARTITION_NAME | SUBPARTITION_NAME | INDEX_NAME | OBJECT_INSTANCE_BEGIN | LOCK_TYPE | LOCK_MODE | LOCK_STATUS | LOCK_DATA |
    +--------+----------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+-----------------+-----------------------+-----------+-----------+-------------+------------------------+
    | INNODB | 2100:1059 | 2100 | 65 | 46 | test | t | NULL | NULL | NULL | 139846618246760 | TABLE | IX | GRANTED | NULL |
    | INNODB | 2100:2:5:1 | 2100 | 65 | 46 | test | t | NULL | NULL | xid | 139846618243720 | RECORD | X | WAITING | supremum pseudo-record |
    | INNODB | 2099:1059 | 2099 | 67 | 28 | test | t | NULL | NULL | NULL | 139846618240760 | TABLE | IX | GRANTED | NULL |
    | INNODB | 2099:2:5:6 | 2099 | 67 | 28 | test | t | NULL | NULL | xid | 139846618237880 | RECORD | X,GAP | WAITING | 9, 0x000000000205 |
    | INNODB | 2098:1059 | 2098 | 66 | 40 | test | t | NULL | NULL | NULL | 139846618234776 | TABLE | IX | GRANTED | NULL |
    | INNODB | 2098:2:5:5 | 2098 | 66 | 40 | test | t | NULL | NULL | xid | 139846618231848 | RECORD | X,GAP | WAITING | 7, 0x000000000203 |
    | INNODB | 2097:1059 | 2097 | 64 | 75 | test | t | NULL | NULL | NULL | 139846618228824 | TABLE | IX | GRANTED | NULL |
    | INNODB | 2097:2:5:1 | 2097 | 64 | 75 | test | t | NULL | NULL | xid | 139846618225784 | RECORD | X | GRANTED | supremum pseudo-record |
    | INNODB | 2097:2:5:5 | 2097 | 64 | 75 | test | t | NULL | NULL | xid | 139846618225784 | RECORD | X | GRANTED | 7, 0x000000000203 |
    | INNODB | 2097:2:5:6 | 2097 | 64 | 75 | test | t | NULL | NULL | xid | 139846618225784 | RECORD | X | GRANTED | 9, 0x000000000205 |
    | INNODB | 2097:2:4:5 | 2097 | 64 | 75 | test | t | NULL | NULL | GEN_CLUST_INDEX | 139846618226128 | RECORD | X | GRANTED | 0x000000000203 |
    | INNODB | 2097:2:4:6 | 2097 | 64 | 75 | test | t | NULL | NULL | GEN_CLUST_INDEX | 139846618226128 | RECORD | X | GRANTED | 0x000000000205 |
    +--------+----------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+-----------------+-----------------------+-----------+-----------+-------------+------------------------+
    12 rows in set (0.00 sec)

事务A造成的锁

| INNODB | 2097:1059 | 2097 | 64 | 75 | test | t | NULL | NULL | NULL | 139846618228824 | TABLE | IX | GRANTED | NULL |
    | INNODB | 2097:2:5:1 | 2097 | 64 | 75 | test | t | NULL | NULL | xid | 139846618225784 | RECORD | X | GRANTED | supremum pseudo-record |
    这里可以看到与之前的不同，上确界添加了X锁，由于使用 select * from t where xid>3 for update; 该表的xid的上确界为9，它需要将9到正无穷也要锁住，supremum pseudo-record 上确界伪记录
    | INNODB | 2097:2:5:5 | 2097 | 64 | 75 | test | t | NULL | NULL | xid | 139846618225784 | RECORD | X | GRANTED | 7, 0x000000000203 |
    | INNODB | 2097:2:5:6 | 2097 | 64 | 75 | test | t | NULL | NULL | xid | 139846618225784 | RECORD | X | GRANTED | 9, 0x000000000205 |
    | INNODB | 2097:2:4:5 | 2097 | 64 | 75 | test | t | NULL | NULL | GEN_CLUST_INDEX | 139846618226128 | RECORD | X | GRANTED | 0x000000000203 |
    | INNODB | 2097:2:4:6 | 2097 | 64 | 75 | test | t | NULL | NULL | GEN_CLUST_INDEX | 139846618226128 | RECORD | X | GRANTED | 0x000000000205 |

下图所示：

![70 15][]

在RR隔离级别下，对一张只有非唯一辅助索引等值当前读和范围当前读造成的锁，以t表为例。

![70 16][]

*  我们可以得出以下结论：   
    在RR隔离级别下，如果表中只有一个非唯一的辅助索引，当进行等值当前读时会与下一行记录形成间隙锁，但不会锁住下一行记录；范围当前读时会与下一行记录形成间隙锁并且会锁住该行。
    
     *  那么可能有人会问在RR隔离级别下，为什么在对辅助索引做范围当前读时会与下一行记录形成间隙锁并且还会锁住该行呢？   
        因为对于非唯一的辅助索引不能保证键值的唯一，所以需要锁住满足条件的下一行进行判断，当然这里还有查询优化器的功劳。
 *  场景三：RR隔离级别下对一张有主键和辅助索引的表做操作

root@localhost : test 10:20:09> select * from t2;
    +----+------+
    | id | xid |
    +----+------+
    | 1 | 1 |
    | 2 | 1 |
    | 4 | 3 |
    | 7 | 7 |
    | 10 | 9 |
    +----+------+
    5 rows in set (0.00 sec)
    root@localhost : test 10:20:02> show index from t2;
    +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+
    | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Visible |
    +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+
    | t2 | 0 | PRIMARY | 1 | id | A | 5 | NULL | NULL | | BTREE | | | YES |
    | t2 | 1 | xid | 1 | xid | A | 4 | NULL | NULL | YES | BTREE | | | YES |
    +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+
    2 rows in set (0.04 sec)

*  等值当前读

![70 17][]

root@localhost : (none) 10:29:14> select * from performance_schema.data_locks;
    +--------+----------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+------------+-----------------------+-----------+-----------+-------------+-----------+
    | ENGINE | ENGINE_LOCK_ID | ENGINE_TRANSACTION_ID | THREAD_ID | EVENT_ID | OBJECT_SCHEMA | OBJECT_NAME | PARTITION_NAME | SUBPARTITION_NAME | INDEX_NAME | OBJECT_INSTANCE_BEGIN | LOCK_TYPE | LOCK_MODE | LOCK_STATUS | LOCK_DATA |
    +--------+----------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+------------+-----------------------+-----------+-----------+-------------+-----------+
    | INNODB | 2070:1061 | 2070 | 65 | 14 | test | t2 | NULL | NULL | NULL | 139846618246760 | TABLE | IX | GRANTED | NULL |
    | INNODB | 2070:4:4:5 | 2070 | 65 | 14 | test | t2 | NULL | NULL | PRIMARY | 139846618243720 | RECORD | X | GRANTED | 7 |
    | INNODB | 2069:1061 | 2069 | 67 | 18 | test | t2 | NULL | NULL | NULL | 139846618240760 | TABLE | IX | GRANTED | NULL |
    | INNODB | 2069:4:5:5 | 2069 | 67 | 18 | test | t2 | NULL | NULL | xid | 139846618237880 | RECORD | X,GAP | WAITING | 7, 7 |
    | INNODB | 2068:1061 | 2068 | 66 | 22 | test | t2 | NULL | NULL | NULL | 139846618234776 | TABLE | IX | GRANTED | NULL |
    | INNODB | 2068:4:5:4 | 2068 | 66 | 22 | test | t2 | NULL | NULL | xid | 139846618231848 | RECORD | X,GAP | WAITING | 3, 4 |
    | INNODB | 2065:1061 | 2065 | 64 | 43 | test | t2 | NULL | NULL | NULL | 139846618228824 | TABLE | IX | GRANTED | NULL |
    | INNODB | 2065:4:5:4 | 2065 | 64 | 43 | test | t2 | NULL | NULL | xid | 139846618225784 | RECORD | X | GRANTED | 3, 4 |
    | INNODB | 2065:4:4:4 | 2065 | 64 | 43 | test | t2 | NULL | NULL | PRIMARY | 139846618226128 | RECORD | X | GRANTED | 4 |
    | INNODB | 2065:4:5:5 | 2065 | 64 | 43 | test | t2 | NULL | NULL | xid | 139846618226472 | RECORD | X,GAP | GRANTED | 7, 7 |
    +--------+----------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+------------+-----------------------+-----------+-----------+-------------+-----------+
    10 rows in set (0.01 sec)

事务A造成的锁下图所示：

| INNODB | 2065:1061 | 2065 | 64 | 43 | test | t2 | NULL | NULL | NULL | 139846618228824 | TABLE | IX | GRANTED | NULL |
    | INNODB | 2065:4:5:4 | 2065 | 64 | 43 | test | t2 | NULL | NULL | xid | 139846618225784 | RECORD | X | GRANTED | 3, 4 |
    | INNODB | 2065:4:4:4 | 2065 | 64 | 43 | test | t2 | NULL | NULL | PRIMARY | 139846618226128 | RECORD | X | GRANTED | 4 |
    | INNODB | 2065:4:5:5 | 2065 | 64 | 43 | test | t2 | NULL | NULL | xid | 139846618226472 | RECORD | X,GAP | GRANTED | 7, 7 |

![70 18][]

![70 19][]

分析：在RR隔离级别下，一张带有主键和非唯一的辅助索引表，使用辅助索引进行当前读时与只有非唯一的辅助索引表进行等值当前读时，都不会将辅助索引的下一行记录进行加锁，只会将下一行记录与前一行记录添加间隙锁。

*  范围当前读

![70 20][]

事务A的造成的锁：

root@localhost : test 11:07:47> select * from performance_schema.data_locks;
    +--------+----------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+------------+-----------------------+-----------+-----------+-------------+-----------+
    | ENGINE | ENGINE_LOCK_ID | ENGINE_TRANSACTION_ID | THREAD_ID | EVENT_ID | OBJECT_SCHEMA | OBJECT_NAME | PARTITION_NAME | SUBPARTITION_NAME | INDEX_NAME | OBJECT_INSTANCE_BEGIN | LOCK_TYPE | LOCK_MODE | LOCK_STATUS | LOCK_DATA |
    +--------+----------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+------------+-----------------------+-----------+-----------+-------------+-----------+
    | INNODB | 2086:1061 | 2086 | 64 | 52 | test | t2 | NULL | NULL | NULL | 139846618228824 | TABLE | IX | GRANTED | NULL |
    | INNODB | 2086:4:5:4 | 2086 | 64 | 52 | test | t2 | NULL | NULL | xid | 139846618225784 | RECORD | X | GRANTED | 3, 4 |
    | INNODB | 2086:4:5:5 | 2086 | 64 | 52 | test | t2 | NULL | NULL | xid | 139846618225784 | RECORD | X | GRANTED | 7, 7 |
    | INNODB | 2086:4:5:6 | 2086 | 64 | 52 | test | t2 | NULL | NULL | xid | 139846618225784 | RECORD | X | GRANTED | 9, 10 |
    | INNODB | 2086:4:4:4 | 2086 | 64 | 52 | test | t2 | NULL | NULL | PRIMARY | 139846618226128 | RECORD | X | GRANTED | 4 |
    | INNODB | 2086:4:4:5 | 2086 | 64 | 52 | test | t2 | NULL | NULL | PRIMARY | 139846618226128 | RECORD | X | GRANTED | 7 |
    | INNODB | 2086:4:4:6 | 2086 | 64 | 52 | test | t2 | NULL | NULL | PRIMARY | 139846618226128 | RECORD | X | GRANTED | 10 |
    +--------+----------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+------------+-----------------------+-----------+-----------+-------------+-----------+
    7 rows in set (0.00 sec)

![70 21][]

![70 22][]

总结

综上所述，在RR隔离级别下的加锁方式：

![70 23][]

说明：对于唯一键值的锁定，next\_key lock 降级为 Record lock 仅存在于查询所有的唯一索引列。如果唯一索引有多个列组成，而查询仅是多个唯一索引列中的一个，那么查询其实是rang类型的查询，而不是point类型的查询，故innodb存储引擎依然使用next\_key lock进行锁定。

![70 24][]

该篇文章包含了在RR隔离级别下的DML语句的加锁情况，DML语句都是当前读，可能有人会问那insert是如何进行加锁的，其实在整个过程中可以发现，在innodb存储引擎中，对于insert操作，其都会检查插入记录的下一条记录是否已经被锁定，若被锁定，则不允许查询，所以我们的每次插入都会失败，返回请求锁超时。下篇将为大家详细描述insert是如何加锁！

**参考资料： **  
https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html   
http://mysql.taobao.org/monthly/2018/05/04/   
http://mysql.taobao.org/monthly/2016/01/01/   
http://hedengcheng.com/?p=771

**|  作者简介**

**王波，沃趣科技数据库技术专家**

熟悉MySQL内部机制、丰富的主从复制故障诊断解决、性能优化、不同场景下数据库备份恢复及迁移经验。

[70]: /images/20220519/dbc8ed362e4949b4bea881a8e5b35722.png
[70 1]: /images/20220519/dc08c04c21874089a5899ef437664025.png
[70 2]: /images/20220519/d34773e0c50c44b69cda2338848ed358.png
[70 3]: /images/20220519/8db29e870b6b4222a979047be89b4e81.png
[70 4]: /images/20220519/e2ee627a6a7b47ad8903b0f108e700ef.png
[70 5]: /images/20220519/92eac612326d4084bf8c6c6cfe8eb541.png
[70 6]: /images/20220519/a236caacdd944cc38c03cdebbf59bf1a.png
[70 7]: /images/20220519/48d90ebb113f4218806e6fa2d7c0ef9c.png
[70 8]: /images/20220519/eb25a127895746a8ba5b55eea7b0dc02.png
[70 9]: /images/20220519/45ae137c594d4dbd86d4ddba7fb7a7bb.png
[70 10]: /images/20220519/383fd0dbc0e5452197c1c709d4c1c140.png
[70 11]: /images/20220519/5b528cd318824d08b29c58713228539d.png
[70 12]: /images/20220519/6bb06415dbbf4cc7801c92d3f2fba4c4.png
[70 13]: /images/20220519/035d3a7386724b5cbc8c909a4d667727.png
[70 14]: /images/20220519/bf076f2e0241417b820d3529785729d4.png
[70 15]: /images/20220519/1e3d7c8f80524b70b1bd4ccba9db8eea.png
[70 16]: /images/20220519/f1777b21e9674f15a8c606ba40bb71ef.png
[70 17]: /images/20220519/0e2e2160768b4012ac8658905542869c.png
[70 18]: /images/20220519/a2a0200cb294496f9fe75922184bc563.png
[70 19]: /images/20220519/b39e6bbf4e6343648f3a7db039ebfb27.png
[70 20]: /images/20220519/ca8b8a8591794515b6f5a2c706b9b948.png
[70 21]: /images/20220519/4f7c1b3f08ff472aa52db0f2183f3986.png
[70 22]: /images/20220519/cf9929c7b3904b65bc1e5adaa4f1d0b2.png
[70 23]: /images/20220519/4705cd27ef8e47609bca4f7b4ccac11d.png
[70 24]: /images/20220519/8a34225eaa7943dc9beee882c45432e7.png