用到的表如下：
mysql> create table t(
-> a int primary key
-> )engine=InnoDB;
Query OK, 0 rows affected (0.01 sec)
mysql> insert into t values(1),(2),(4),(5);
Query OK, 4 rows affected (0.00 sec)
Records: 4 Duplicates: 0 Warnings: 0
mysql> select * from t;
+–+
| a |
+–+
| 1 |
| 2 |
| 4 |
| 5 |
+–+
4 rows in set (0.00 sec)
问题：
1.上面文字说到：”这个问题由于会话B中请求记录4的S锁而发生等待，但之前请求的锁对于主键记录1、2都已经成功，“
这里的1、2成功指的能否是共享锁成功？ 假如是的话，为什么3没有加共享锁成功？
2.能不能详细解释一下上述死锁现象？
mysql> create table t(
-> a int primary key
-> )engine=InnoDB;
Query OK, 0 rows affected (0.01 sec)
mysql> insert into t values(1),(2),(4),(5);
Query OK, 4 rows affected (0.00 sec)
Records: 4 Duplicates: 0 Warnings: 0
mysql> select * from t;
+–+
| a |
+–+
| 1 |
| 2 |
| 4 |
| 5 |
+–+
4 rows in set (0.00 sec)
问题：
1.上面文字说到：”这个问题由于会话B中请求记录4的S锁而发生等待，但之前请求的锁对于主键记录1、2都已经成功，“
这里的1、2成功指的能否是共享锁成功？ 假如是的话，为什么3没有加共享锁成功？
2.能不能详细解释一下上述死锁现象？
解决方案
20
1/2 是开启事务，并没有锁
3 查询的时候指定 FOR UPDATE，这时候记录持有X锁，所以3成功
4. SHARE MODEL 申请共享锁（S)，由于3已经持有X锁，S与X冲突，所以4等等（也就是不成功）
5. 申请锁要等待4成功，4要等待3成功，5和3在同一会话，也就是会话A/B互相等待了，符合死锁规则，于是本人会话A中止，全部的锁释放，既然会话A的锁都释放了，会话B的4也就能成功了
3 查询的时候指定 FOR UPDATE，这时候记录持有X锁，所以3成功
4. SHARE MODEL 申请共享锁（S)，由于3已经持有X锁，S与X冲突，所以4等等（也就是不成功）
5. 申请锁要等待4成功，4要等待3成功，5和3在同一会话，也就是会话A/B互相等待了，符合死锁规则，于是本人会话A中止，全部的锁释放，既然会话A的锁都释放了，会话B的4也就能成功了
20
是
记录3此时还未插入
建议直接本人开三个mysql命令窗口，然后模拟测试以验证。 毕竟实践是检验的最好方法。