老师你好,去年双11碰到了dbcrash掉的情况.至今没有找到答案,心里渗得慌.老师帮忙分析下.
我是一个开发,关于db的知识更多是在应用和基本原理上面,实在是找不到原因. 我也搜了一些资料 感觉像是mysql的bug,不过在其buglist中没有找到完全一致的，当然也可能是我们业务也许导致库的压力大的原因.
应用端看到的现象是db没有响应，应用需要访问db的线程全部僵死.db表现是hang住 , 当时的诊断日志如下，表面表现为一直获取不到latch锁（被一个insert线程持有不释放） https://note.youdao.com/ynoteshare1/index.html?id=1771445db3ff1e08cbdd8328ea6765a7&type=note#/ 隔离级别是rr

同样的crash双11当天后面又出现了一次（哭死）,
都是重启数据库解决的,

后面应用层面做了一样优化,没有再crash过，优化主要如下：
1.减小读压力，去除一些不必要的查询，
2.优化前，有并发事务写和查询同一条数据记录，即事务a执行insert 尚未提交，事务b就来查询（快照读），优化后保证查询时insert事务已经提交

老师，我想问下：insert 语句出现唯一键冲突，会加next-key lock，而产生死锁的例子中，同样也是唯一键冲突却只加了记录锁，然后我按照唯一键冲突中的两个例子试了试
1、比如t表中有两条记录(19,19,19)，(22,22,22)，这时候我再insert (22,22,22)造成了主键冲突，这时候加的就是(19,22]的next-key lock，这个insert为啥不是等值查询？
2、根据死锁的例子，我又在t表中准备插入一行
      session A :begin; insert into t values (25,25,25)
      session B :insert into t values (25,25,25) 这时候sessionB锁等待
      session C：insert into t values (24,24,24) 锁等待，等B锁等待超时，session C插入成功
      那这里的session B应该是加了个(22,25]的next-key lock，并没有因为是唯一键退化成记录锁
我想死锁的例子中t表已经有了(1,1,1),(2,2,2),(3,3,3),(4,4,4)4条记录，这时候insert (null,5,5)，是不是加的(4,5]这个next-key lock，由于是整型并且间隙非常小，所以将他当成记录锁？

对这个SQL 执行过程的解释，
insert into t(c,d) (select c+1, d from t force index(c) order by c desc limit 1);

>由于实现上这个语句没有在子查询中就直接使用 limit 1，从而导致了这个语句的执行需要遍历整个表 t。
没太看懂“由于”那句话，既然在子查询中有了limit 1，为什么不能只把最后一条记录插入临时表呢？
老师能在说明一下吗？

MySQL8.0.12环境下，
执行insert into t(c,d) (select c+1, d from t force index(c) order by c desc limit 1);
slow log Rows_examined: 2
Innodb_rows_read 的值增加1

是不是MySQL8进行了优化，先把子查询的结果读出来，再写入临时表？

老师，之前提到的一个有趣的问题"A、B两个用户，如果互相喜欢，则成为好友。设计上是有两张表，一个是like表，一个是friend表，like表有user_id、liker_id两个字段，我设置为复合唯一索引即uk_user_id_liker_id。语句执行顺序是这样的：
以A喜欢B为例：
1、先查询对方有没有喜欢自己（B有没有喜欢A）
select * from like where user_id = B and liker_id = A
2、如果有，则成为好友
insert into friend
3、没有，则只是喜欢关系
insert into like"，这个问题中如果把select语句改成"当前读"，则当出现A,B两个人同时喜欢对方的情况下，是不是会出现由于"当前读"加的gap锁导致后面insert语句阻塞，从而发生死锁？

老师，也许问题有点傻，不过我还是想问一下。
锁，在计算机世界中是非常重要的，只要有并发必然会有锁，这个锁不像这把🔒，看的见也常见很容易理解。
1：锁，在计算机世界究竟是个什么东西？一种数据结构？一句计算机命令？一种同步机制？在JAVA中有许多锁的类，能产生锁的对象，实现锁的功能，但是它怎么锁的？我很好奇，没完全弄明白。
2：锁，是怎么实现的？是打个标记嘛？新来的线程一看有标记就等着，自己也打一个。JAVA中看到过用一个变量当锁，进入锁变量加一解锁变量减一，这样根据变量值就知道是否加锁了，MySQL也是如此吗？
3：锁，说加在索引上，这个加在索引上怎么加的呢？索引是一棵树，也是以一个对象的形式存在的吗？
总是听到这个锁那个锁的，我觉得没有理解锁的本质是啥，或者锁这个概念是操作系统世界的词，在操作系统层面更容易理解一些，在各种应用软件中就是一段代码，只是功能和现实中锁门的锁的功能相似而已。
4：有等待就有唤醒，唤醒就是唤醒线程嘛？这个唤醒就怎么唤醒呢？是从等待的队列中获取一个线程嘛？那他又怎么知道之前执行到哪？该怎么执行啦？

老师，看到您的回复，当select c+1, d from t force index(c) order by c desc limit 1;这条语句单独执行是会在c索引上加(4,sup] 这个next key lock, 于是我进行了尝试
sessionA:
begin;
select c+1, d from t3 force index(c) order by c desc limit 1;
sessionB:
insert into t3 values(5, 5, 5);
结果是，sessionB插入成功，是不是我哪里理解错了？我的版本是5.7.23

老师，能帮忙看下这个死锁记录吗？对于duplicate key插入有什么阻止的好方法？LATEST DETECTED DEADLOCK
------------------------
190222 8:37:45
*** (1) TRANSACTION:
TRANSACTION 16FEC1AE, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 6 lock struct(s), heap size 1248, 3 row lock(s)
MySQL thread id 169973, OS thread handle 0x2ba0fa040700, query id 41915315 10.45.133.181 W59FFHKU
INSERT INTO resource (
                        Id
                      , Name
                      , Date
                      , User
                    ) VALUES (99127, 'RS_2098185e367d11e9878202a98a7af318', '', 'JR')
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 78 page no 71 n bits 160 index `PRIMARY` of table `resource` trx id 16FEC1AE 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;;
*** (2) TRANSACTION:
TRANSACTION 16FEC1AF, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
6 lock struct(s), heap size 1248, 3 row lock(s)
MySQL thread id 169996, OS thread handle 0x2ba0ffec2700, query id 41915317 10.45.133.181 W59FFHKU
INSERT INTO resource (
                        Id
                      , Name
                      , Date
                      , User
                    ) VALUES (99125, 'RS_2098b778367d11e9878202a98a7af318', '', 'JR')
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 78 page no 71 n bits 160 index `PRIMARY` of table `resource` trx id 16FEC1AF lock mode S
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 78 page no 71 n bits 160 index `PRIMARY` of table `resource` trx id 16FEC1AF 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;;
*** WE ROLL BACK TRANSACTION (2)

老师您好：
关于文中的锁描述有所疑惑。

文中出现过 共享的next-key锁 和 排他的next-key锁。

我们知道next-key是由 gap lock 和 行锁组成的。

我一直以来的认知是 gap lock都是s锁，没有x锁。
而行锁有s锁和x锁。
比如 select………lock in share mode，行锁是s
锁。
比如select………for update，行锁就是x锁。
但是gap lock 始终是s锁。

文中直接描述next-key lock是排他的，总让我认为gap lock和行锁都是x锁。

不知道我理解得对不对？