1 什么是间隙锁 什么是next-key lock
2 它们的加锁规则?
3 间隙锁在RR下才有
4 间隙锁 ( x,x ] 前开后闭
5 查找过程访问到的才会加锁
6 索引的 =查询 , 对唯一索引加锁的话 , net-key lock会退化为行锁
7 索引的 =查询 , 向右遍历到最后一个不满足等值条件的时候, next-key lock退化为间隙锁
8 一个bug : 唯一索引的范围查询会访问到不满足条件的第一个值才停止
9 next-key lock = 行锁+间隙锁
10 案例1 : 在id5和id10之间update id 7 , 由于没有id7 , 添加nextkeylock (5,10] 并退化为间隙锁(5,10)
11 session b 此时要插入id8 ,会被block
12 案例2画图分析
13 lock in share mode , 读锁也会加next-key lock , 是加锁的基本单位 , (0,5)
14 next-key lock退化成间隙锁的另一个案例 , 额外加锁的一个案例
15 由于是覆盖索引 , 没有访问主键索引 , 因此主键索引上没有锁 , session b 的查询不会被block
16 session c被间隙锁block
17 lock in share mode 只锁覆盖索引, 但是for update会认为你需要更新数据 , 因此也会被主键索引上满足条件的行加锁
18 锁是加在索引上的 , 如果想避免没有锁主键索引的情况 , 就要绕过覆盖索引的优化
19 案例3 范围查询
20 案例4 非唯一索引范围锁
21 案例5 唯一索引范围锁bug
22 后面还有很多案例 , 每一个都要自己画图分析一下加锁过程
23 删除加上limit会缩小锁的范围
24 间隙锁的阻塞关系和行锁不一样 : 参考第20讲 , 跟间隙锁存在冲突关系的，是“往这个间隙中插入一个记录”这个操作。间隙锁之间都不存在冲突关系。
贴一张行锁的读写锁进行对比
其实是这样的，session B的“加next-key lock(5,10] ”操作，实际上分成了两步，先是加(5,10)的间隙锁，加锁成功；然后加c=10的行锁，这时候才被锁住的。
25 上面都是RR级别下的 , 同时由于两阶段锁协议 , 事务在提交或回滚才会释放锁
26 RC的话就没有间隙锁了
27 一道加锁分析题
28 上面还有一道死锁案例
