yibo2018

@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 ，但是目前看下来也没有（没阻塞）

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

问题一：
事务一种 S1 会在 t2 表产生共享锁，事务二 insert t2 首先会插入意向写锁，所以阻塞

问题二：
事务一运行 S1 同上，所以事务二运行 t2 的 for update / lock in share model 应该会阻塞！但是并没有阻塞，和问题一的答案相悖

问题三：
如果问题一回答的是正确的，那么是可以解释的