[轉] MySQL死鎖問題分析及解決方法實例詳解

轉自：http://www.phpstudy.net/b.php...

MySQL死鎖問題是不少程序員在項目開發中常遇到的問題，現就MySQL死鎖及解決方法詳解以下：

一、MySQL經常使用存儲引擎的鎖機制

MyISAM和MEMORY採用表級鎖(table-level locking)

BDB採用頁面鎖(page-level locking)或表級鎖，默認爲頁面鎖

InnoDB支持行級鎖(row-level locking)和表級鎖,默認爲行級鎖

二、各類鎖特色

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

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

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

三、各類鎖的適用場景

表級鎖更適合於以查詢爲主,只有少許按索引條件更新數據的應用,如Web應用

行級鎖則更適合於有大量按索引條件併發更新數據,同時又有併發查詢的應用,如一些在線事務處理系統

四、死鎖

是指兩個或兩個以上的進程在執行過程當中,因爭奪資源而形成的一種互相等待的現象,若無外力做用,它們都將沒法推動下去。

表級鎖不會產生死鎖.因此解決死鎖主要仍是針對於最經常使用的InnoDB.

五、死鎖舉例分析

在MySQL中，行級鎖並非直接鎖記錄，而是鎖索引。索引分爲主鍵索引和非主鍵索引兩種，若是一條sql語句操做了主鍵索引，MySQL就會鎖定這條主鍵索引；若是一條語句操做了非主鍵索引，MySQL會先鎖定該非主鍵索引，再鎖定相關的主鍵索引。

在UPDATE、DELETE操做時，MySQL不只鎖定WHERE條件掃描過的全部索引記錄，並且會鎖定相鄰的鍵值，即所謂的next-key locking。

例如，一個表db.tab_test，結構以下：

id：主鍵；
state：狀態；
time：時間；
索引：idx_1 (state, time)

出現死鎖日誌以下：

***(1) TRANSACTION: 
TRANSACTION 0 677833455, ACTIVE 0 sec, process no 11393, OS thread id 278546 starting index read 
mysql tables in use 1, locked 1 
LOCK WAIT 3 lock struct(s), heap size 320 
MySQL thread id 83, query id 162348740 dcnet03 dcnet Searching rows for update 
update tab_test set state=1064,time=now() where state=1061 and time < date_sub(now(), INTERVAL 30 minute) （任務1的sql語句） 
***(1) WAITING FOR THIS LOCK TO BE GRANTED: （任務1等待的索引記錄） 
RECORD LOCKS space id 0 page no 849384 n bits 208 index `PRIMARY` of table `db/tab_test` trx id 0 677833455 _mode X locks rec but not gap waiting 
Record lock, heap no 92 PHYSICAL RECORD: n_fields 11; compact format; info bits 0 
0: len 8; hex 800000000097629c; asc b ;; 1: len 6; hex 00002866eaee; asc (f ;; 2: len 7; hex 00000d40040110; asc @ ;; 3: len 8; hex 80000000000050b2; asc P ;; 4: len 8; hex 800000000000502a; asc P*;; 5: len 8; hex 8000000000005426; asc T&;; 6: len 8; hex 800012412c66d29c; asc A,f ;; 7: len 23; hex 75706c6f6164666972652e636f6d2f6 8616e642e706870; asc xxx.com/;; 8: len 8; hex 800000000000042b; asc +;; 9: len 4; hex 474bfa2b; asc GK +;; 10: len 8; hex 8000000000004e24; asc N$;; 
*** (2) TRANSACTION: 
TRANSACTION 0 677833454, ACTIVE 0 sec, process no 11397, OS thread id 344086 updating or deleting, thread declared inside InnoDB 499 
mysql tables in use 1, locked 1 
3 lock struct(s), heap size 320, undo log entries 1 
MySQL thread id 84, query id 162348739 dcnet03 dcnet Updating update tab_test set state=1067,time=now () where id in (9921180) （任務2的sql語句） 
*** (2) HOLDS THE LOCK(S): （任務2已得到的鎖） 
RECORD LOCKS space id 0 page no 849384 n bits 208 index `PRIMARY` of table `db/tab_test` trx id 0 677833454 lock_mode X locks rec but not gap 
Record lock, heap no 92 PHYSICAL RECORD: n_fields 11; compact format; info bits 0 
0: len 8; hex 800000000097629c; asc b ;; 1: len 6; hex 00002866eaee; asc (f ;; 2: len 7; hex 00000d40040110; asc @ ;; 3: len 8; hex 80000000000050b2; asc P ;; 4: len 8; hex 800000000000502a; asc P*;; 5: len 8; hex 8000000000005426; asc T&;; 6: len 8; hex 800012412c66d29c; asc A,f ;; 7: len 23; hex 75706c6f6164666972652e636f6d2f6 8616e642e706870; asc uploadfire.com/hand.php;; 8: len 8; hex 800000000000042b; asc +;; 9: len 4; hex 474bfa2b; asc GK +;; 10: len 8; hex 8000000000004e24; asc N$;; 
*** (2) WAITING FOR THIS LOCK TO BE GRANTED: （任務2等待的鎖） 
RECORD LOCKS space id 0 page no 843102 n bits 600 index `idx_1` of table `db/tab_test` trx id 0 677833454 lock_mode X locks rec but not gap waiting  
Record lock, heap no 395 PHYSICAL RECORD: n_fields 3; compact format; info bits 0 
0: len 8; hex 8000000000000425; asc %;; 1: len 8; hex 800012412c66d29c; asc A,f ;; 2: len 8; hex 800000000097629c; asc b ;; 
*** WE ROLL BACK TRANSACTION (1) 
（回滾了任務1，以解除死鎖）

緣由分析：

當「update tab_test set state=1064,time=now() where state=1061 and time < date_sub(now(), INTERVAL 30 minute)」執行時，MySQL會使用idx_1索引，所以首先鎖定相關的索引記錄，由於idx_1是非主鍵索引，爲執行該語句，MySQL還會鎖定主鍵索引。

假設「update tab_test set state=1067,time=now () where id in (9921180)」幾乎同時執行時，本語句首先鎖定主鍵索引，因爲須要更新state的值，因此還須要鎖定idx_1的某些索引記錄。

這樣第一條語句鎖定了idx_1的記錄，等待主鍵索引，而第二條語句則鎖定了主鍵索引記錄，而等待idx_1的記錄，這樣死鎖就產生了。

六、解決辦法

拆分第一條sql，先查出符合條件的主鍵值，再按照主鍵更新記錄：

select id from tab_test where state=1061 and time < date_sub(now(), INTERVAL 30 minute);
update tab_test state=1064,time=now() where id in(......);

至此MySQL死鎖問題得以解決！