自己原文公众号： https://mp.weixin.qq.com/s/WM6L80iYqfQtGAu-uUguIA
谈谈死锁。这种好理解也不好理解。说好理解是因为一句话可以概况：相互等待。但是实际发生的确实有时候让人捉摸不透。
比如A会话执行 B会话执行
1 update t1 set xx where id=1; 2 update t2 set xx where id=2;
3 update t2 set xx where id=2; 4 update t1 set xx where id=1;
1/2/3/4分别表示执行顺序。这里t1和t2可以是两个表，也可以是一张表。
他会立即弹出检测到死锁的字样。很快。因为无解，所以必须放弃一个。
但是有的时候执行show engine innodb status我们会看到长时间的等待。这里才十几秒，其实几百秒的也有。这是为什么呢？
那可能是锁和死锁都出现了。
假设一种情况：红色表示执行的先后顺序。
1执行了没有及时提交，导致4堵住了。这样245这三步都因为4在等待而走不下去，而3在等5，所以35这两步因为3在等也走不下去了。只要1一旦提交。就可以进入45两步，这个时候6一旦出现就是最简单的死锁。
这个模拟只是我们假设了一种比较简单的场景模拟锁和死锁的混合。实际情况你可以想想只要1的那个步骤再复杂一点，甚至多很多会话，每个事务中不仅仅只有2个简单的update，那么复杂度就直线上升。实际情况其实是乱成一团麻，但是万变不离其宗，原理就这样。
解决方法还是要执行的快，以及按照相同顺序依次执行SQL。
