RR|RC隔离级别下行锁的情况

测试准备

test库下建表tt

CREATE TABLE `tt` (
  `id` int(11) NOT NULL,
  `code` int(11) DEFAULT NULL,
  `name` varchar(50) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `vers` varchar(20) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `version` varchar(30) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_code` (`code`),
  KEY `idx_name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

插入值

INSERT INTO TEST.TT VALUES(1,1,'name1','5.7.11', '7');
INSERT INTO TEST.TT VALUES(2,2,'name2','5.7.12','8');
INSERT INTO TEST.TT VALUES(3,3,'name2','V5.7','9');
INSERT INTO TEST.TT VALUES(4,3,'name4','5.7.15','10');
INSERT INTO TEST.TT VALUES(5,6,'name6','5.7.16','11');
INSERT INTO TEST.TT VALUES(6,7,'name7','v5.7','12');

打开InnoDB锁监控，具体参考https://dev.mysql.com/doc/refman/8.0/en/innodb-enabling-monitors.html：

SET GLOBAL innodb_status_output=ON;
SET GLOBAL innodb_status_output_locks=ON;

RR（repeatable-read）隔离级别

情况一

session1：

sql>begin;
sql>update tt set vers='vsss' where code=3 and name='name2'; ##执行计划是index merge（两个索引联合了）

session2:

sql>update tt set vers='xx' where name='name2' and version=8;
...等待，直到50s超时

查看show engine innodb status \G

=====================================
2021-06-10 17:31:37 0x7f2fac9aa700 INNODB MONITOR OUTPUT
=====================================
...
...
MySQL thread id 24, OS thread handle 139842735195904, query id 219 localhost root updating
update tt set vers='xx' where name='name2' and version=8
------- TRX HAS BEEN WAITING 14 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 34 page no 5 n bits 80 index idx_name of table `test`.`tt` trx id 6977 lock_mode X waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 5; hex 6e616d6532; asc name2;;
 1: len 4; hex 80000002; asc     ;;
...

结论：上述dml，会话1 update所更改的二级索引值所在的gap范围会加锁，假如会话2更改的行所在的二级索引值在会话1的gap范围，则会话2在会话1的二级索引上等待锁。二级索引会对（单独用该索引）搜索到的行加锁（其他过滤条件不影响加锁行的范围）。（此种情况为二级索引情况）

情况二

session1

sql>begin;
sql>update tt set vers='vsss' where code=3 and name<='name2' and name >'name1'; ##执行计划走code索引

session2

sql>update tt set vers='ssss' where name='name2' and version=8; ##执行计划走name索引

查看show engine innodb status \G

=====================================
2021-06-10 19:44:29 0x7f2fac9aa700 INNODB MONITOR OUTPUT
=====================================
...
...
MySQL thread id 26, OS thread handle 139842735736576, query id 252 localhost root updating
update tt set vers='ssss' where name='name2' and version=8
------- TRX HAS BEEN WAITING 6 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 34 page no 3 n bits 96 index PRIMARY of table `test`.`tt` trx id 6990 lock_mode X locks rec but not gap waiting
Record lock, heap no 15 PHYSICAL RECORD: n_fields 7; compact format; info bits 0
 0: len 4; hex 80000003; asc     ;;
 1: len 6; hex 000000001b4b; asc      K;;
 2: len 7; hex 32000001410282; asc 2   A  ;;
 3: len 4; hex 80000003; asc     ;;
 4: len 5; hex 6e616d6532; asc name2;;
 5: len 4; hex 76737373; asc vsss;;
 6: len 1; hex 39; asc 9;;
...

结论：session1和session2采用的是不同索引，索引session2是在等待session1的primary值为9的行记录的锁。（此种情况为主键锁等待）

情况三

修改tt表

sql>update tt set id=10 where code=6;
sql>select * from tt;
+----+------+-------+--------+---------+
| id | code | name  | vers   | version |
+----+------+-------+--------+---------+
|  1 |    1 | name1 | 5.7.11 | 7       |
|  2 |    2 | name2 | 5.7.12 | 8       |
|  3 |    3 | name2 | V5.7   | 9       |
|  4 |    3 | name4 | 5.7.15 | 10      |
|  6 |    7 | name7 | v5.7   | 12      |
| 10 |    6 | name6 | 5.7.16 | 11      |
+----+------+-------+--------+---------+

session1

sql>begin;
sql>update tt set vers='XXXBB' where code=3;

session2

sql>insert into tt values(5,6,'name99','v5.7.28','13');
...等待，直到50s超时
sql>insert into tt values(8,6,'name99','v5.7.28','13');
...等待，直到50s超时
sql>insert into tt values(11,6,'name99','v5.7.28','13');
Query OK, 1 row affected (0.00 sec)

结论：这个范围还跟主键有关

RC（read-commit）隔离级别

情况一

session1

sql>begin;
sql>update tt set vers='vsss' where version='9' and name='name2';

session2

sql>update tt set vers='XXXXXcccc' where name='name2' and version='8';
...等待，直到50s超时

sql>update tt force index(idx_name) set vers='XXXXXcccc' where name='name2' and id=2;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0 
[可以成功执行]

查看show engine innodb status \G

=====================================
2021-06-10 20:31:13 0x7f58d064d700 INNODB MONITOR OUTPUT
=====================================
...
...
------------
TRANSACTIONS
------------...
---TRANSACTION 7947, ACTIVE 8 sec fetching rows
mysql tables in use 1, locked 1
LOCK WAIT 4 lock struct(s), heap size 1136, 3 row lock(s), undo log entries 1
MySQL thread id 2, OS thread handle 140019430659840, query id 24 localhost root updating
update tt set vers='XXXXXcccc' where name='name2' and version=8
------- TRX HAS BEEN WAITING 8 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 34 page no 5 n bits 80 index idx_name of table `test`.`tt` trx id 7947 lock_mode X locks rec but not gap waiting
Record lock, heap no 4 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 5; hex 6e616d6532; asc name2;;
 1: len 4; hex 80000003; asc     ;;
 
------------------
TABLE LOCK table `test`.`tt` trx id 7947 lock mode IX
RECORD LOCKS space id 34 page no 5 n bits 80 index idx_name of table `test`.`tt` trx id 7947 lock_mode X locks rec but not gap
Record lock, heap no 3 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 5; hex 6e616d6532; asc name2;;
 1: len 4; hex 80000002; asc     ;;
 
RECORD LOCKS space id 34 page no 3 n bits 96 index PRIMARY of table `test`.`tt` trx id 7947 lock_mode X locks rec but not gap
Record lock, heap no 31 PHYSICAL RECORD: n_fields 7; compact format; info bits 0
 0: len 4; hex 80000002; asc     ;;
 1: len 6; hex 000000001f0b; asc       ;;
 2: len 7; hex 280000016001ca; asc (   `  ;;
 3: len 4; hex 80000002; asc     ;;
 4: len 5; hex 6e616d6532; asc name2;;
 5: len 9; hex 585858585863636363; asc XXXXXcccc;;
 6: len 1; hex 38; asc 8;;
 
RECORD LOCKS space id 34 page no 5 n bits 80 index idx_name of table `test`.`tt` trx id 7947 lock_mode X locks rec but not gap waiting
Record lock, heap no 4 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 5; hex 6e616d6532; asc name2;;
 1: len 4; hex 80000003; asc     ;;
 
---TRANSACTION 7946, ACTIVE 99 sec
3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 3, OS thread handle 140019430389504, query id 22 localhost root
TABLE LOCK table `test`.`tt` trx id 7946 lock mode IX
RECORD LOCKS space id 34 page no 5 n bits 80 index idx_name of table `test`.`tt` trx id 7946 lock_mode X locks rec but not gap
Record lock, heap no 4 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 5; hex 6e616d6532; asc name2;;
 1: len 4; hex 80000003; asc     ;;
 
RECORD LOCKS space id 34 page no 3 n bits 96 index PRIMARY of table `test`.`tt` trx id 7946 lock_mode X locks rec but not gap
Record lock, heap no 15 PHYSICAL RECORD: n_fields 7; compact format; info bits 0
 0: len 4; hex 80000003; asc     ;;
 1: len 6; hex 000000001f0a; asc       ;;
 2: len 7; hex 270000013a031e; asc '   :  ;;
 3: len 4; hex 80000003; asc     ;;
 4: len 5; hex 6e616d6532; asc name2;;
 5: len 4; hex 76737373; asc vsss;;
 6: len 1; hex 39; asc 9;;
...
...

结论：会话1通过name索引（和version=9）找到一行记录，并在该二级索引值（[name='name2',id=3]）上加锁；这时会话2通过name索引（找到两行：[name='name2',id=2] [name='name2',id=3]），这时会等待 [name='name2',id=3]二级索引值记录行上的锁。（此种情况一开始会对二级索引所检索的值加锁 [例如有2行]，根据其他条件 [过滤了一行] 找到的primary key [1行]，则在这行primary key和二级索引 [过滤了一行] 的key上加锁，过滤掉的一行二级索引值的锁释放）