咨询了 gpt:结论如下:
对于示例中的数据库事务:
初步执行 time1: update student set score=88 where id=22; 时,因为 id=22 并不存在,所以它会添加一个 Next-key lock ,范围在项目 (15, 25) 上。
然后 time2: update student set score=99 where id=21; 可以被成功执行,而不会被阻塞,这是因为 InnoDB 使用了 Next-key Locks (即记录锁和间隙锁的组合)。执行这条语句时,id=21 并不存在,不会触发 Next-key Locks 范围 (15, 25) 上的记录锁,并成功执行。但同时,这个语句添加了一个 Next-key lock ,范围在 (21, 25) 上。
然后在 time3: insert into student(id, name, age, score) value(22, 'John', 28, 88); 语句执行时,因为 id=22 在之前 time2 执行的 Next-key Locks 泛围 (21, 25) 内,所以这条语句会被阻塞。
同时,在 time4:insert into student(id, name, age, score) value(21, 'John', 28, 99); 中,因为 id=21 在事务 A 的 Next-key Locks 泛围 (15, 25) 内,所以这条语句亦会阻塞。
最后形成了死锁,两个操作互相等待对方释放资源。