21 | 为什么我只改一行的语句，锁这么多？

老师，您好。假期的没跟上，今天补到了这节课，看了之后有几点不是太明白。望能解答一下。 1. 索引c上的锁算不算是行锁。假如索引c上的next-key lock为(0,5] (5,10]，那么5算不算是c上的行锁？ 2. 在案例六中，执行 “delete from t where c=10;” 语句，索引c上的next-key lock是(5,10],(10,10],(10,15)。那么主键索引上的锁是什么呢？是只有行锁，锁住的是 (10,10,10) 和 (30,10,30) 两行吗？ 3. 也是在案例六中，session A不变，在session B中执行 “update t_20 set d=50 where c=5;”、“update t_20 set d=50 where c=15;”、“insert into t_20 values(40,15,40);”均执行成功，但执行“insert into t_20 values(50,5,50);” 时，却被阻塞。为什么呢？具体执行语句如下 session A mysql> begin; mysql> explain delete from t_20 where c=10; id select_type table partitions type possible_keys key key_len ref rows filtered Extra 1 DELETE t_20 range c c 5 const 2 100 Using where mysql> delete from t_20 where c=10; session B mysql> update t_20 set d=50 where c=5; Query OK, 1 row affected (0.01 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> update t_20 set d=50 where c=15; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> insert into t_20 values(40,15,40); Query OK, 1 row affected (0.00 sec) mysql> explain insert into t_20 values(50,5,50); +----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+ | 1 | INSERT | t_20 | NULL | ALL | c | NULL | NULL | NULL | NULL | NULL | NULL | +----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+ 1 row in set (0.00 sec) mysql> insert into t_20 values(50,5,50); （block） 我使用的mysql版本是：5.7.23-0ubuntu0.16.04.1 show variables的结果太多，我截取了一部分，或许对您分析有帮助： innodb_version 5.7.23 protocol_version 10 slave_type_conversions tls_version TLSv1,TLSv1.1 version 5.7.23-0ubuntu0.16.04.1 version_comment (Ubuntu) version_compile_machine x86_64 version_compile_os Linux

是不是可以总结为： 1、查询过程中访问到的对象才会加锁，而加锁的基本单位是next-key lock（前开后闭）； 2、等值查询上MySQL的优化：索引上的等值查询，如果是唯一索引，next-key lock会退化为行锁，如果不是唯一索引，需要访问到第一个不满足条件的值，此时next-key lock会退化为间隙锁； 3、范围查询：无论是否是唯一索引，范围查询都需要访问到不满足条件的第一个值为止；

遇到一个有趣的问题，在老师的解答下终于弄明白了： CREATE TABLE z ( id INT PRIMARY KEY AUTO_INCREMENT, b INT, KEY b(b) ) ENGINE = InnoDB DEFAULT CHARSET = utf8; INSERT INTO z (id, b) VALUES (1, 2), (3, 4), (5, 6), (7, 8), (9, 10); session A BEGIN; SELECT * FROM z WHERE b = 6 FOR UPDATE; session B INSERT INTO z VALUES (0, 4); 这里为什么会被锁住 答案比较长，写在我自己的笔记里了，地址是 https://helloworlde.github.io/blog/blog/MySQL/MySQL-%E4%B8%AD%E5%85%B3%E4%BA%8Egap-lock-next-key-lock-%E7%9A%84%E4%B8%80%E4%B8%AA%E9%97%AE%E9%A2%98.html 大家可以看看

老师，你好： 我练习实例的时候发现一个问题：如 案例五：唯一索引范围锁 bug begin; select * from t where id>10 and id<=15 for update; 1、执行如上语句加锁范围(10,15]和(15,20]； 2、因为10未加锁，所以我单独再开一个连接，执行delete from t where id=10;不会锁等待，能正常删除； 3、但是我再执行insert into t values(10,10,10); 语句会等待，无法正常执行； 4、经过分析我发现第一个连接执行的语句的加锁范围已经变成(5,15]和(15,20]，代表锁蔓延了；这是什么原因呢？

首先老师新年快乐，学习专栏受益良多！ 上期问过老师的问题已了解答案，锁是加在索引上的。再尝试回答问题。c上是普通索引，根据原则2，访问到的都要加锁，在查询c>=15这个条件时，在查找到15后加锁（10，15］，继续往右查找，按理说不会锁住6这个索引值，但查询语句中加了order by c desc，我猜想会优化为使用c<=20这条语句，查找到20后往左查找，这样会访问到15左边的值10，从而加锁（5，10］，不知我理解对否？

不好意思，这次又来晚了，看这种连载技术文章，和看小说一样，养肥了集中看~~ 这次的问题如下，希望丁老师有空解答一下。 版本：mysql 5.6.39 CREATE TABLE `t` ( `a` int(11) NOT NULL, `b` int(11) DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8; insert into t values(1,1),(2,2),(3,3),(4,4),(5,5); 采用READ-COMMITTED隔离级别 案例1、 session A： begin; update t set a=6 where b=1; session B： begin; update t set a=7 where b=2; A和B均能执行成功 问题1：官档上说对于RC且全表扫描的update，先逐行添加行锁然后释放掉不符合where条件的，那么session A成功对(1,1)加锁，理论上session B在扫描(1,1)并尝试加锁时会被阻塞，为何还能执行成功？官档链接：https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html 案例2： session A： begin; update t set a=6 where b=1; session B： begin; delete from t where b=2; -- 被阻塞 问题2：为何案例1 中的session B不会被阻塞，而案例2的却被session A的行数阻塞，update和delete都是全部扫描，难道加锁机制不一样？

老师，案例八session B的操作语句update t set d = d + 1 where c =10; 由于c是非唯一键索引，锁（5，10」可以理解 ，为什么不锁(10,15} 呢，不是应该继续向后扫描直到第一个不满足条件的值为止吗

老师在案列一中update t set d=d+1 where id=7 中id是主键也是唯一索引，按优化1应该退化成行锁才对，为什么insert into t values(8,8,8)会被锁住，我是那儿理解错了?

老师您好。在自己跑案例四的时候，回想起之前MVCC的内容就对案例做了些调整，此时产生一些有关一致性试图的疑惑，还想请老师排疑解惑。 MySQL8.0.13，RR隔离级别下，表结构及数据按照例子中不变，执行语句如下： session A：begin; select * from t where c>=10 and c<11 for update; --锁住(5,15] session B：update t set d=d+1 where c=5; --成功，changed:1 session A：select * from t; --读到d=6 此时，session A居然读到了session B update后的结果。语句调整后，把session A中的 for update去掉，依据RR级别下一致性视图原理不会读到session B更新后的结果。 那么，是否可以理解begin后执行的select语句使用for update/lock in share mode并不会生成一致性视图呢？ 还请老师指点迷津，感激不尽(❁´ω`❁)

早晨睡不着打开极客时间一看，竟然更新了。今天是周日而且在假期中哎...