咨询了 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) 内，所以这条语句亦会阻塞。
最后形成了死锁，两个操作互相等待对方释放资源。
peyppicp 最近的时间轴更新
Select Language