Mysql并發時經典常見的死鎖原因及解決方法

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是會自動從小到大排序，加鎖也是一條條從小到大加的鎖

案例2：

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

當對存在的行進行鎖的時候(主鍵)，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：

直接上情景：

這個跟案例一其它是差不多的情況，隻是session1不按常理出牌了，

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

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

附記，推薦兩篇好文章

案例4：

http://hedengcheng.com/?p=844

mysql 加鎖處理分析：

http://hedengcheng.com/?p=771

« 上一篇：mysql 随機字元的産生方法

» 下一篇：虛拟機service network restart沒有反應解決方法