精选留言(125)

• 
  堕落天使 置顶

  2019-01-03

   9

  老师，您好。假期的没跟上，今天补到了这节课，看了之后有几点不是太明白。望能解答一下。
  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 就是间隙锁➕行锁，所以包含=5这一行
  2. 对
  3. (c=5,id=50)是在这个gap里哦，你试试插入(1,5,50)对比一下。好问题

• 
  张三

  2018-12-31

   43

  Happy New Year !这个专栏绝对是极客时间最好我买过最值的专栏。
• 
  约书亚

  2018-12-31

   13

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

  作者回复: 风雨无阻 节假日不休，包括元旦和春节😄

• 
  undifined

  2019-01-07

   7

  遇到一个有趣的问题，在老师的解答下终于弄明白了：
  
  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
  
  大家可以看看

  展开

  作者回复: 好问题，质量很高的笔记

• 
  HuaMax

  2019-01-01

   5

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

  展开

  作者回复: 新年好
  
  对的👍🏿

• 
  郭江伟

  2018-12-31

   5

  老师这次的留下的问题，语句跟上次不一样，上期问题语句是select id from t where c>=15 and c<=20 order by c desc for update;；这次缺少了 order by c desc ，不加desc的话insert into t values(6,6,6);不会被堵塞；
  根据优化3：索引上的等值查询，在向右遍历时且最后一个值不满足等值条件的时候next-key lock退化为间隙锁；
  问题中的sql语句加了desc ，是向左扫描，该优化用不上，所以下限10是闭区间，为了防止c为10的行加入，需要锁定到索引c键（5,5）
  此例中insert into t values(6,5,6) 会堵塞，insert into t values(4,5,6) 不会堵塞，

  展开

  作者回复: 嗯你说的对
  
  不过是我少打一个词了，加上去了，要desc哦
  
  重新分析下😄

• 
  Leon📷

  2019-01-29

   4

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

  展开

  作者回复: 好问题，新年快乐
  
  会锁的，只是因为在(5,10]就被锁住了，所以后面的锁加不上去了😆

• 
  Geek_9ca34...

  2019-01-09

   4

  老师，你好：
  我练习实例的时候发现一个问题：如 案例五：唯一索引范围锁 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]，代表锁蔓延了；这是什么原因呢？

  展开

  作者回复: 好问题，我会加到答疑文章中，
  Gap是一个动态的概念

• 
  乾坤

  2019-01-01

   4

  您好，关于"优化 2：索引上的等值查询，向右遍历时且最后一个值不满足等值条件的时候，next-key lock 退化为间隙锁。"，我觉得改为"从第一个满足等值条件的索引记录开始向右遍历到第一个不满足等值条件记录，并将第一个不满足等值条件记录上的next-key lock 退化为间隙锁"更明确些

  展开

  作者回复: 感觉没大差别，嗯嗯，理解就好😄

• 
  往事随风，...

  2019-01-01

   3

  这和分两步有什么关系？
  (5,10]已经是被锁住，分不分两步来加锁，这个间隙和行锁都被锁住了，session b应该是拿不到锁才对。

  展开
• 
  Geek_maxwe...

  2019-04-14

   2

  老师有个疑问，就是既然repeat read已经解决了幻读（利用next key lock)，那下一个事务级别（序列化）主要是解决什么问题呢？ 因为原本我以为repeat read 其实没有解决幻读
• null

  2019-04-13

   2

  @唯她命 的问题，案例一为啥是间隙锁，而不是行锁？
  
  我自己的理解：因为 id=7 的记录不存在，没有上锁的实体，所以无法使用优化 1。
  
  优化 1 是说索引上的等值查询，如果是唯一索引，且记录存在，就退化成行锁。
  优化 2 是说在索引上的等值查询，不管是唯一索引，还是非唯一索引，只有向右遍历时，最后一个值不等于等值查询的条件，就会退化成间隙锁。如 where id=7，扫描完 id=5，接着扫描 id=10，但是 7 不等于 10，所以会退化成间隙锁。
  
  如果理解有误，还望老师指正😁😁

  展开
• 
  木子

  2019-05-14

   1

  老师，你好，回头看第二遍的时候，突然发现一个地方没明白：在案例1中 id=7等值查询时，id是主键，也满足唯一索引，为什么没有根据优化1 next-key lock 退化为行锁而是加了（5,10）的间隙锁？而案例三中 主键索引范围锁案例中 第一步 找到id=10的记录 这时候是根据优化2 主键索引上的等值查询 退化为行锁？同样是主键索引的等值查询为什么一个加了间隙锁一个退化成了行锁？麻烦老师看到之后回复一下，非常感谢

  展开
• null

  2019-04-14

   1

  @坠落天使 的问题，案例六的 session A 不变，session B insert (c=5, id=50) 的记录被 block，可以借用“线段”的概念来帮助理解，下面是我自己的理解：
  session A 我们只关注 a (c=5, id=5) 和 b (c=10, id=10) 这两个点 (为了方便说明，其他的锁我们选择忽略)。
  在平面上，a 和 b两点连成的线段，就是我们的加锁范围。
  现在有一个点 f(c=5, id=6) 需要插入线段中，因为 a 和 f 的 c 值都是 5，但是 f 的 id 比 a 的 id 要大，所以在线段上表示，f 在 a 的右边，落入了线段内，即落入了锁区间，所以被 block 了。
  有一个点 e(c=5, id=4) 需要在平面展示，同理 e 点是在 a 点的左边，没落到锁区间，所以 insert 成功。

  展开
• 
  唯她命

  2019-03-23

   1

  老师，唯一索引的等值查询 退换成 行锁，案例一的等值查询为啥是间隙锁？？
• 
  Barnett

  2019-03-10

   1

  老师，您好，关于精选留言中堕落天使的第三个问题，next-key lock是(5,10],(10,10],(10,15)，您的回答是(c=5,id=50)也是在这个gap里的。但是5不是开区间的吗？

  作者回复: (5,10]是个简写
  
  其实就是左边界是 （c=5,id=5) , 右边界是(c=10, id=10)，
  
  左开右闭
  
  这样你再看下这个结论😆
  
  

• 
  时隐时现

  2019-01-30

   1

  不好意思，这次又来晚了，看这种连载技术文章，和看小说一样，养肥了集中看~~
  这次的问题如下，希望丁老师有空解答一下。
  版本：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都是全部扫描，难道加锁机制不一样？

  展开

  作者回复:
  好问题，在read-commited隔离级别下，update语句
  有一个“semi-consistent” read优化，
  
  意思是，如果update语句碰到一个已经被锁了的行，会读入最新的版本，然后判断一下是不是满足查询条件，
  a)如果不满足，就直接跳过；
  b) 如果满足，才进入锁等待
  
  你的第二个问题：这个策略，只对update有效，delete无效
  
  新春快乐~

• happy涛

  2019-01-23

   1

  老师：同上一个问题。 还是案例2. select id from t where c=6 for update;
  ID为[0,9)都不可以添加，包括-1都可以。为啥会锁这么多。而c锁的是[5,10),大于等于5，小于10
  

  作者回复: select id from t where c=6 for update;
  这个在c上的锁是（5，10）这个间隙

• 
  堕落天使

  2019-01-04

   1

  堕落天使：
  老师，您好。假期的没跟上，今天补到了这节课，看了之后有几点不是太明白。望能解答一下。
  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);” 时，却被阻塞。为什么呢？
  作者回复
  1. Next-key lock 就是间隙锁➕行锁，所以包含=5这一行
  2. 对
  3. (c=5,id=50)是在这个gap里哦，你试试插入(1,5,50)对比一下。好问题
  
  我的回复：
  老师，您好：
  在第三个问题中，对于索引c的锁应该是 (5,10]、(10,10]、(10,15)；主键索引上的锁为行锁，是“(10,10,10) 和 (30,10,30) ”两行记录。那么(c=5,id=50) 是在哪个间隙锁上呢？是还没有讲还是我粗心没看到呢？另外经过您的启发，我在 sessio B 中又插入了几条记录，如下:
  “insert into t_20 values(1,5,50);”、“insert into t_20 values(60,1,50);”、“insert into t_20 values(80,4,50);” 、“insert into t_20 values(70,15,50);” 均插入成功。
  但插入“insert into t_20 values(100,5,50);”、“insert into t_20 values(300,5,50);”均被阻塞。
  我大胆猜想一下，(c=5,id=50) 的间隙锁是不是"c=5 并且 id=(30,+suprenum]" ？

  展开

  作者回复: 我觉得案例6、7就是讲到了哦，普通索引是带着主键值的；
  
  应该说(c=5,id=50)所在的间隙是 (c=5,id=5)到(c=10,id=10)
  
  你可以像案例5那样自己画个索引图

• 
  往事随风，...

  2019-01-01

   1

  session A
  mysql> select * from t where c>=15 and c<=20 order by c desc lock in share mode;
  +----+------+------+
  | id | c | d |
  +----+------+------+
  | 20 | 20 | 20 |
  | 15 | 15 | 15 |
  +----+------+------+
  2 rows in set (0.00 sec)
  
  session b
  mysql> insert into t values(6,6,6);
  Query OK, 1 row affected (0.00 sec)
  可以插入成功，没有被锁住

  展开

  作者回复: Explain结果发一下，还有show variables 结果也发下