老师，新年好，有几个问题：
问题一：
对于文中的第一个例子（不等号条件里的等值查询），当试图去找 “第一个id<12的值"的时候，用的还是从左往右的遍历（因为用到了优化2），也就是说，当去找第一个等值的时候（通过树搜索去定位记录的时候），即使order by desc，但用的还是向右遍历，当找到了第一个等值的时候（例子中的id=15），然后根据order by desc，再向左遍历。
是不是这么理解？

问题二：
对于第21讲的思考题， select * from t where c>=15 and c<=20 order by c desc lock in share mode， 老师已经给出了答案，我这里再详细理解一下：
先定位索引c上最右边c=20的行，所以第一个等值查询会扫描到c=25，然后通过优化2，next-key lock退化为间隙锁，则会加上间隙锁（20，25），紧接着再向左遍历，会加 next-key lock (15, 20], (10, 15], 因为要扫描到c=10才停下来，所以也会加next-key lock (5,10]
理解的是否正确？

问题三：
对于上面的问题二的sql，在索引c上，把（10，25）这段区间锁上就应该是完备的了，理论上（5，10]这段区间是否锁上对结果应该没有影响呀。
是不是说MySQL就是这么实现的，next-key lock前开后闭，因为扫到了c=10，所以会加next-key lock (5,10]，这里MySQL的实现扩大了锁的区间范围，其实没有这个必要？
另外，如果不加next-key lock (5,10]，是不是这里c=10还是应该要锁的，如果不锁可能被删除？

对于问题 我理解是这样
session 1：
delete from t;
begin; select * from t for update;
session 2:
insert into t values(1,1,1);发生等待
show engine innodb status\G;
.....
------- TRX HAS BEEN WAITING 5 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 75 page no 3 n bits 72 index PRIMARY of table `test`.`t` trx id 752090 lock_mode X insert intention waiting
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;
其中申请插入意向锁与间隙锁 冲突，supremum这个能否理解为 间隙右边的那个记录

先说结论：空表锁 (-supernum，supernum],老师提到过mysql的正无穷是supernum，在没有数据的情况下，next-key lock 应该是supernum前面的间隙加 supernum的行锁。但是前开后闭的区间，前面的值是什么我也不知道，就写了一个-supernum。
稍微验证一下
session 1）
begin;
select * from t where id>9 for update;
session 2）
begin;
insert into t values(0,0,0),(5,5,5);
（block）

老师好!不知道还看得见么。很矛盾啊有个地方。
begin;
select * from t where id>9 and id<12 order by id desc for update;
加锁方位是(0,5]..(10.15)。加锁时是找到第一个不满足的条件然后加一个前开后闭的。所以(0,5]也被加锁了，可以。
但是到了下一个
begin;
select id from t where c in(5,20,10) lock in share mode;
在查找 c=5 的时候，先锁住了 (0,5]。但是因为 c 不是唯一索引，为了确认还有没有别的记录 c=5，就要向右遍历，找到 c=10 才确认没有了，这个过程满足优化 2，所以加了间隙锁 (5,10)。
你可能会说，这个加锁范围，不就是从 (5,25) 中去掉 c=15 的行锁吗？为什么这么麻烦地分段说呢？
下面这个加锁范围到底是多少啊?。
(0,25)还是(5,25)?c不是唯一索引不符合优化条件。之前9那一行。对(0,5]＋了锁。第一个不满足条件的是0，为啥不对(-xx，0]加锁呢?

为什么我在5.6的版本上 测试 文中最后2个死锁的案例都没有复现 （rr，rc都测试了，没有复现死锁）
CREATE TABLE `t` (
  `id` int(11) NOT NULL,
  `c` int(11) DEFAULT NULL,
  `d` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `i_c` (`c`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1；
gaotuan[test]11:17:59>select * from t;
+----+------+------+
| id | c | d |
+----+------+------+
| 0 | 0 | 0 |
| 1 | 1 | 1 |
| 5 | 5 | 5 |
| 10 | 10 | 10 |
| 15 | 15 | 15 |
| 20 | 20 | 20 |
| 25 | 25 | 25 |
+----+------+------+
session1：
gaotuan[test]11:02:04>begin;
Query OK, 0 rows affected (0.00 sec)

gaotuan[test]11:02:07>select c from t where c>5 lock in share mode;
+------+
| c |
+------+
| 10 |
| 15 |
| 20 |
| 25 |
+------+
4 rows in set (0.00 sec)

session2：
gaotuan[test]11:05:08>begin;
Query OK, 0 rows affected (0.00 sec)

gaotuan[test]11:05:11>
gaotuan[test]11:05:13>delete from t where id=10;
Query OK, 1 row affected (0.00 sec)

gaotuan[test]11:05:19>insert into t values(10,10,10);
Query OK, 1 row affected (0.00 sec)

gaotuan[test]11:05:30>rollback;

有个很奇怪的现象
session a: begin; select * from cd where c <= 10 for update;
session b: select * from cd where c = 15 for update;
此时session b会被block
session a稍作修改
session a: begin; select * from cd where c = 10 for update;
session b: select * from cd where c = 15 for update;
此时session b不会被阻塞住。我理解即使c<=10这种也不应该阻塞c=15。
我理解的加锁过程是等值查找到c=10这一行，向右遍历 next-key lock为（10，15]，根据优化2退化为(10,15) 。但是实验结果令人费解

老师，您好：
         对文中以下语句感到有困惑：
我们说加锁单位是 next-key lock，都是前开后闭区，但是这里用到了优化 2，即索引上的等值查询，向右遍历的时候id=15不满足条件，所以 next-key lock 退化为了间隙锁 (10, 15)。
SQL语句中条件中使用的是id字段（唯一索引），那么根据加锁规则这里不应该用的是优化 2，而是优化 1，因为优化1中明确指出给唯一索引加锁，从而优化 2的字面意思来理解，它适用于普通索引。不知道是不是我理解的不到位？