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的行记录的锁。（此种情况为主键锁等待）
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上加锁，过滤掉的一行二级索引值的锁释放）
标签：隔离,RR,hex,len,asc,name2,RC,id,name 来源： https://www.cnblogs.com/jiangxm157/p/14872860.html