Mysql併發時經典常見的死鎖緣由及解決方法

1.    mysql都有什麼鎖

 

MySQL有三種鎖的級別：頁級、表級、行級。

表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖衝突的機率最高,併發度最低。

行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖衝突的機率最低,併發度也最高。

頁面鎖：開銷和加鎖時間界於表鎖和行鎖之間；會出現死鎖；鎖定粒度界於表鎖和行鎖之間，併發度通常

 

算法：

next KeyLocks鎖，同時鎖住記錄(數據)，而且鎖住記錄前面的Gap    

Gap鎖，不鎖記錄，僅僅記錄前面的Gap

Recordlock鎖（鎖數據，不鎖Gap）

因此其實 Next-KeyLocks=Gap鎖+ Recordlock鎖

 

2.    什麼狀況下會形成死鎖

 

所謂死鎖<DeadLock>: 是指兩個或兩個以上的進程在執行過程當中,
因爭奪資源而形成的一種互相等待的現象,若無外力做用,它們都將沒法推動下去.
此時稱系統處於死鎖狀態或系統產生了死鎖,這些永遠在互相等竺的進程稱爲死鎖進程.
表級鎖不會產生死鎖.因此解決死鎖主要仍是針對於最經常使用的InnoDB.

 

死鎖的關鍵在於：兩個(或以上)的Session加鎖的順序不一致。

那麼對應的解決死鎖問題的關鍵就是：讓不一樣的session加鎖有次序

 

3.    一些常見的死鎖案例

 

案例一：

需求：將投資的錢拆成幾份隨機分配給借款人。

起初業務程序思路是這樣的：

投資人投資後，將金額隨機分爲幾份，而後隨機從借款人表裏面選幾個，而後經過一條條select for update 去更新借款人表裏面的餘額等。

 

抽象出來就是一個session經過for循環會有幾條以下的語句：

Select * from xxx where id='隨機id' for update

 

基原本說，程序開啓後不一會就死鎖。

這能夠是說最經典的死鎖情形了。

 

例如兩個用戶同時投資，A用戶金額隨機分爲2份，分給借款人1，2

B用戶金額隨機分爲2份，分給借款人2，1

因爲加鎖的順序不同，死鎖固然很快就出現了。

 

對於這個問題的改進很簡單，直接把全部分配到的借款人直接一次鎖住就好了。

Select * from xxx where id in (xx,xx,xx) for update

在in裏面的列表值mysql是會自動從小到大排序，加鎖也是一條條從小到大加的鎖

 

 

例如（如下會話id爲主鍵）：

Session1:

mysql> select * from t3 where id in (8,9) for update;

+----+--------+------+---------------------+

| id | course | name | ctime               |

+----+--------+------+---------------------+

|  8 | WA     | f    | 2016-03-02 11:36:30 |

|  9 | JX     | f    | 2016-03-01 11:36:30 |

+----+--------+------+---------------------+

2 rows in set (0.04 sec)

 

 

Session2:

select * from t3 where id in (10,8,5) for update;

鎖等待中……

其實這個時候id=10這條記錄沒有被鎖住的，但id=5的記錄已經被鎖住了，鎖的等待在id=8的這裏。

 

不信請看

Session3:

mysql> select * from t3 where id=5 for update;

鎖等待中

 

Session4:

mysql> select * from t3 where id=10 for update;

+----+--------+------+---------------------+

| id | course | name | ctime               |

+----+--------+------+---------------------+

| 10 | JB     | g    | 2016-03-10 11:45:05 |

+----+--------+------+---------------------+

1 row in set (0.00 sec)

 

在其它session中id=5是加不了鎖的，可是id=10是能夠加上鎖的。

 

 

 

 

案例2：

在開發中，常常會作這類的判斷需求：根據字段值查詢（有索引），若是不存在，則插入；不然更新。

 

以id爲主鍵爲例，目前尚未id=22的行

Session1:

select * from t3 where id=22 for update;

Empty set (0.00 sec)

 

session2:

select * from t3 where id=23  for update;

Empty set (0.00 sec)

 

Session1:

insert into t3 values(22,'ac','a',now());

鎖等待中……

 

Session2:

insert into t3 values(23,'bc','b',now());

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

 

當對存在的行進行鎖的時候(主鍵)，mysql就只有行鎖。

當對未存在的行進行鎖的時候(即便條件爲主鍵)，mysql是會鎖住一段範圍（有gap鎖）

 

 

鎖住的範圍爲：

(無窮小或小於表中鎖住id的最大值，無窮大或大於表中鎖住id的最小值)

 

如：若是表中目前有已有的id爲（11 ， 12）

那麼就鎖住（12，無窮大）

若是表中目前已有的id爲（11 ， 30）

那麼就鎖住（11，30）

 

對於這種死鎖的解決辦法是：

insert into t3(xx,xx) on duplicate key update `xx`='XX';

 

用mysql特有的語法來解決此問題。由於insert語句對於主鍵來講，插入的行無論有沒有存在，都會只有行鎖。

 

 

案例3：

直接上情景：

mysql> select * from t3 where id=9 for update;

+----+--------+------+---------------------+

| id | course | name | ctime               |

+----+--------+------+---------------------+

|  9 | JX     | f    | 2016-03-01 11:36:30 |

+----+--------+------+---------------------+

1 row in set (0.00 sec)

 

Session2:

mysql> select * from t3 where id<20 for update;

鎖等待中

 

Session1:

mysql> insert into t3 values(7,'ae','a',now());

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

 

 

這個跟案例一其它是差很少的狀況，只是session1不按常理出牌了，

Session2在等待Session1的id=9的鎖，session2又持了1到8的鎖（注意9到19的範圍並無被session2鎖住），最後，session1在插入新行時又得等待session2,故死鎖發生了。

 

這種通常是在業務需求中基本不會出現，由於你鎖住了id=9，卻又想插入id=7的行，這就有點跳了，固然確定也有解決的方法，那就是重理業務需求，避免這樣的寫法。

 

另一個死鎖介紹的博客地址：http://www.cnblogs.com/LBSer/p/5183300.html