老师之前的留言说错了，重新梳理下： 图8：间隙锁导致的死锁；我把innodb_locks_unsafe_for_binlog设置为1之后，session B并不会blocked，session A insert会阻塞住，但是不会提示死锁；然后session B提交执行成功，session A提示主键冲突 这个是因为将innodb_locks_unsafe_for_binlog设置为1之后，什么原因造成的？

老师，今天的文章对我影响很大，发现之前掌握的知识有些错误的地方，课后我用你的表结构根据以前不清楚的地方实践了一遍，现在有两个问题，麻烦您解答下 1.我在事务1中执行 begin;select * from t where c=5 for update;事务未提交，然后事务2中begin;update t set c=5 where id=0;执行阻塞，替换成update t set c=11 where id=0;执行不阻塞，我觉得原因是事务1执行时产生next-key lock范围是(0,5].(5,10]。我想问下update set操作c=xxx是会加锁吗？以及加锁的原理。 2.一直以为gap只会在二级索引上，看了你的死锁案例，发现主键索引上也会有gap锁？

说真的，这一系列文章实用性真的很强，老师非常负责，想必牵扯到老师大量精力，希望老师再出好文章，谢谢您了，辛苦了

可重复读隔离级别下，经试验： SELECT * FROM t where c>=15 and c<=20 for update; 会加如下锁： next-key lock:(10, 15], (15, 20] gap lock:(20, 25) SELECT * FROM t where c>=15 and c<=20 order by c desc for update; 会加如下锁： next-key lock:(5, 10], (10, 15], (15, 20] gap lock:(20, 25) session C 被锁住的原因就是根据索引 c 逆序排序后多出的 next-key lock:(5, 10] 同时我有个疑问：加不加 next-key lock:(5, 10] 好像都不会影响到 session A 可重复读的语义，那么为什么要加这个锁呢？

看了@令狐少侠 提出的问题，对锁有了新的认识： 对于非索引字段进行update或select .. for update操作，代价极高。所有记录上锁，以及所有间隔的锁。 对于索引字段进行上述操作，代价一般。只有索引字段本身和附近的间隔会被加锁。 这次终于明白，为什么说update语句的代价高！

通过打印锁日志帮助理解问题 锁信息见括号里的说明。 TABLE LOCK table `guo_test`.`t` trx id 105275 lock mode IX RECORD LOCKS space id 31 page no 4 n bits 80 index c of table `guo_test`.`t` trx id 105275 lock_mode X Record lock, heap no 4 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 ----(Next-Key Lock，索引锁c（5，10]) 0: len 4; hex 8000000a; asc ;; 1: len 4; hex 8000000a; asc ;; Record lock, heap no 5 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 ----(Next-Key Lock，索引锁c (10,15]) 0: len 4; hex 8000000f; asc ;; 1: len 4; hex 8000000f; asc ;; Record lock, heap no 6 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 ----(Next-Key Lock，索引锁c (15,20]) 0: len 4; hex 80000014; asc ;; 1: len 4; hex 80000014; asc ;; Record lock, heap no 7 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 ----(Next-Key Lock，索引锁c (20,25]) 0: len 4; hex 80000019; asc ;; 1: len 4; hex 80000019; asc ;; RECORD LOCKS space id 31 page no 3 n bits 80 index PRIMARY of table `guo_test`.`t` trx id 105275 lock_mode X locks rec but not gap Record lock, heap no 5 PHYSICAL RECORD: n_fields 5; compact format; info bits 0 ----(记录锁 锁c=15对应的主键） 0: len 4; hex 8000000f; asc ;; 1: len 6; hex 0000000199e3; asc ;; 2: len 7; hex ca000001470134; asc G 4;; 3: len 4; hex 8000000f; asc ;; 4: len 4; hex 8000000f; asc ;; Record lock, heap no 6 PHYSICAL RECORD: n_fields 5; compact format; info bits 0 0: len 4; hex 80000014; asc ;; ----(记录锁 锁c=20对应的主键） 1: len 6; hex 0000000199e3; asc ;; 2: len 7; hex ca000001470140; asc G @;; 3: len 4; hex 80000014; asc ;; 4: len 4; hex 80000014; asc ;; 由于字数限制，正序及无排序的日志无法帖出，倒序日志比这两者，多了范围(Next-Key Lock，索引锁c（5，10])，个人理解是，加锁分两次，第一次，即正序的锁，第二次为倒序的锁，即多出的(5,10],在RR隔离级别， innodb在加锁的过程中会默认向后锁一个记录，加上Next-Key Lock,第一次加锁的时候10已经在范围，由于倒序，向后，即向5再加Next-key Lock,即多出的(5,10]范围

这样，当你执行 select * from t where d=5 for update 的时候，就不止是给数据库中已有的 6 个记录加上了行锁，还同时加了 还同时加了 7 个间隙锁 --------------------------------------------------------------- 老師這句話沒看太明白，數據庫只有一條d=5的記錄，為什麼會給6個記錄加上行鎖呢？

insert into t values(0,0,0),(5,5,5), (10,10,10),(15,15,15),(20,20,20),(25,25,25); 运行mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> select * from t where c>=15 and c<=20 order by c desc for update; c 索引会在最右侧包含主键值，c索引的值为(0,0) (5,5) (10,10) (15,15) (20,20) (25,25) 此时c索引上锁的范围其实还要匹配主键值 。 思考题答案是，上限会扫到c索引(20,20) 上一个键，为了防止c为20 主键值小于25 的行插入，需要锁定(20,20) (25,25) 两者的间隙；开启另一会话(26,25,25)可以插入，而(24,25,25)会被堵塞。 下限会扫描到(15,15)的下一个键也就是(10,10),测试语句会继续扫描一个键就是(5,5) ，此时会锁定，(5,5) 到(15,15)的间隙，由于id是主键不可重复所以下限也是闭区间； 在本例的测试数据中添加(21,25,25)后就可以正常插入(24,25,25)

老师 ， 看到幻读的定义是 ： 幻读是一个事物在前后两次查询同一个范围的时候，后一次查询看到了前一次查询没有看到的行 。 那么我感觉 1. 读提交事务隔离级别 2.可重复读事务隔离级别的当前读 这两个都符合这个定义 。 那是不是说 在 1 、 2 条件下都会发生幻读 。 但是我看一些文章都说幻读是rr级别下的 ， rc 是不可重复读 。请问是我理解有误还是文章写的不准确

mysql官方提到自增锁是个表级锁，老师能介绍下这个吗，以及实际项目中高并发insert是否需要避免自增主键？