@bitdepth 你遇到过类似的事情吗？你花了多久时间拿到了 2N ？没有经历过并成功的话，这种话很天真

@HKViolet "AS9808 這張網" 是上海移动专线的别名吗？

我用的移动，动不动就没信号，打个手游都跳 P ，看你们说的这么好，下次就换联通了

@kingfalse 猫晚上不会蹦迪吗？

@oldboy627 都是不善表达之人，生前都没说过几句话，关键是我每次梦中都下意识是正常的，没有意识到已经去世了。梦的过程中又会慢慢想起来爷爷已经去世了。。就是那种后怕

sql 只做基本的功能，业务代码去组合，这样不好吗？否则你一个业务对应一个 sql ，先不说 sql 一定不能覆盖所有业务，其次 sql 的改动涉及到索引，覆盖等问题产生慢查询，死锁问题，都不考虑的？

好多人喷楼主，2 个 join 怎么了，就难懂吗？这不是关键呀，首先多几个 for 循环是没 SQL 查直接快，那又怎样，这根本不会是瓶颈，反而 MySQL 复杂之后引发的各种死锁，慢查询才是瓶颈

我之前都是们在被子里用 kindle 看（已经看过的）小说，这样就还好，并且会很快入睡
除此之外，还有一种也很恐怖，就是我经常梦到过世的爷爷，梦中没有意思到他已经去世了，然后半夜醒来后脊发凉，很是后怕，这种就没办法了，只能起球赶紧再入睡了。
但有一次我经历了上述恐怖事件后，怎么也睡不着，怕的要死，就差敲开合租舍友的门了。。
至于后来嘛，就安稳许多了，因为我床上一直会多一个人：「

不过太明显了，摸鱼也不好打开看

哈哈有点意思，钱还是会动的

前年 3 月份辞职，休息了一年之后，情况就更差了，现在想着准备简历，准备面试，但进度异常缓慢，平常工作也是摸鱼摸鱼。
看了这个帖子后很有感触，目前和同事每天中午去健身，已经持续一年了。在这里写一些积极的措施：
1. 持续进行有规律的进行冥想
2. 恢复使用 focus APP ，工作时间禁用微信，telegram 等干扰因素
3. 和小伙伴实施多次奖罚机制行为

最后打鸡血，我一定可以****

发现大佬，持续关注

@YIERIC 哇塞，感谢大佬，很清晰

@YIERIC 对的，我也很纳闷，这个结论可以说是由问题一反证回来的

@YIERIC 我的理解是 s1 (insert ... exists (select ...)) 这个形式会对 select 的内容上共享锁

@Feiex 嗯，问题三的死锁问题是可以解释的

但是问题 2 就让我很困惑，对 t2 的共享锁（ S1 语句运行）和排它锁（对 t2 进行 for update ）应该是互斥。但其实没有互斥锁。
写着写着突然发现答案了：
那么原因只有一个就是：俩个上锁的地方没有重合！
即便是全表加锁，也会因为 MySQL 自己的优化机制退化。
为了证实上述的点，我选择了一个已经有的条件，会上间隙锁+定向锁，结果是阻塞了

至此我提出来的 3 个问题就解决了，感谢大家

@ozipin 不对哦，我可以试试
我简单的测试了下
事务一
SELECT *
FROM `t2` tmrd
where publish_id = '1123424214' lock in share mode

事务二
SELECT *
FROM `t2` tmrd
where publish_id = '1123424214' for update

事务二阻塞了

换句话说 for update 加的是 X 锁（排它锁）也就是写锁

@Feiex 这句话我理解的就是，会在 t 表上加 X 锁。然后呢？

@orzwalker111 哇塞分析的很详细

问题 2 中
事务一运行 S1 ，如果 publish_id 没有命中的话，会产生全表的间隙锁吧？（自问自答）也不其然，有一个 semi-consistent read 机制，对于不满足查询条件的记录，MySQL 会提前释放，同时不加 GAP 锁，就和你说的退化一样。
但是对于事务 2 的 select ... where publish_id = 1123424214 for update 也是针对全表的排它锁，如果他也退化，至少也要对 1123424214 左右进行 GAP ，但是目前看下来也没有（没阻塞）

翻阅了大量的资料，让我头越来越大，确丝毫用不到自己的问题中，学以致用对我来说真难，我好菜