​MySQL的show engine innodb status

自己原文公眾號： https://mp.weixin.qq.com/s/WM6L80iYqfQtGAu-uUguIA

自己原文公眾號： 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。