主頁 > 知識庫 > MySQL數(shù)據(jù)庫的一次死鎖實(shí)例分析

MySQL數(shù)據(jù)庫的一次死鎖實(shí)例分析

1、故事起因于2016年11月15日的一個(gè)生產(chǎn)bug。業(yè)務(wù)場景是：歸檔一個(gè)表里邊的數(shù)據(jù)到歷史表里邊，同是刪除主表記錄。

2、背景場景簡化如下（數(shù)據(jù)庫引擎InnoDb，數(shù)據(jù)隔離級別RR[REPEATABLE]）

-- 創(chuàng)建表test1 
CREATE TABLE test1 ( 
id int(11) NOT NULL AUTO_INCREMENT, 
name varchar(10) NOT NULL, 
PRIMARY KEY (id) 
); 
insert into test1 values('hello'); 
 
-- 創(chuàng)建表test2 
CREATE TABLE test2 ( 
id int(11) NOT NULL AUTO_INCREMENT, 
name varchar(10) NOT NULL, 
PRIMARY KEY (id) 
); 
 
-- Transcation 1 
begin; 
insert into test2 select * from test1 where id = 1; 
delete from test1 where id = 1; 
 
-- Transcation 2 
begin; 
insert into test2 select * from test1 where id = 1;

3、具體執(zhí)行順序

Transcation1	Transcation2
begin; — 這條sql得到test1表主鍵索引鎖共享鎖S（id=1） insert into test2 select * from test1 where id = 1;
	begin; — 這條sql試圖獲取test1表主鍵索引鎖共享鎖S（id=1），但是已經(jīng)被T1占有，所以它進(jìn)入鎖請求隊(duì)列. insert into test2 select * from test1 where id = 1;
— 這條sql試圖把自己擁有的test1表主鍵索引鎖共享鎖S(id=1）升級為排它鎖X（id=1） — 這時(shí)T1也發(fā)起一個(gè)鎖請求，這個(gè)時(shí)候mysql發(fā)現(xiàn)鎖請求隊(duì)列里邊已存在一個(gè)事物T2對（id=1）的這條記錄申請了S鎖，死鎖產(chǎn)生了。 delete from test1 where id = 1;
	死鎖產(chǎn)生后mysql根據(jù)兩個(gè)事務(wù)的權(quán)重，事務(wù)2的權(quán)重更小，被選為死鎖的犧牲者，rollback。
T2 rollback 之后T1成功獲取了鎖執(zhí)行成功

Mysql 官方解釋

Deadlock occurs here because client A needs an X lock to delete the row. However, that lock request cannot be granted because client B already has a request for an X lock and is waiting for client A to release its S lock. Nor can the S lock held by A be upgraded to an X lock because of the prior request by B for an X lock. As a result, InnoDBgenerates an error for one of the clients and releases its locks. The client returns this error。

實(shí)際場景和mysql文檔有些區(qū)別，文檔里邊要獲取的是X鎖。具體事例里邊要獲取的是S鎖。

下面我們來具體的一步步分析下mysql的死鎖

1、MySQL常用存儲引擎的鎖機(jī)制

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

　　BDB采用頁面鎖(page-level locking)或表級鎖，默認(rèn)為頁面鎖

　　InnoDB支持行級鎖(row-level locking)和表級鎖，默認(rèn)為行級鎖

2、各種鎖特點(diǎn)

　　表級鎖：開銷小，加鎖快;不會出現(xiàn)死鎖;鎖定粒度大，發(fā)生鎖沖突的概率最高，并發(fā)度最低

　　行級鎖：開銷大，加鎖慢;會出現(xiàn)死鎖;鎖定粒度最小，發(fā)生鎖沖突的概率最低，并發(fā)度也最高

　　頁面鎖：開銷和加鎖時(shí)間界于表鎖和行鎖之間;會出現(xiàn)死鎖;鎖定粒度界于表鎖和行鎖之間，并發(fā)度一般

3、各種鎖的適用場景

　　表級鎖更適合于以查詢?yōu)橹?，只有少量按索引條件更新數(shù)據(jù)的應(yīng)用，如Web應(yīng)用

　　行級鎖則更適合于有大量按索引條件并發(fā)更新數(shù)據(jù)，同時(shí)又有并發(fā)查詢的應(yīng)用，如一些在線事務(wù)處理系統(tǒng)

4、死鎖

　　是指兩個(gè)或兩個(gè)以上的進(jìn)程在執(zhí)行過程中，因爭奪資源而造成的一種互相等待的現(xiàn)象，若無外力作用，它們都將無法推進(jìn)下去。

　　表級鎖不會產(chǎn)生死鎖。所以解決死鎖主要還是針對于最常用的InnoDB。

5、死鎖舉例分析

　　在MySQL中，行級鎖并不是直接鎖記錄，而是鎖索引。索引分為主鍵索引和非主鍵索引兩種，如果一條sql語句操作了主鍵索引，MySQL就會鎖定這條主鍵索引;如果一條語句操作了非主鍵索引，MySQL會先鎖定該非主鍵索引，再鎖定相關(guān)的主鍵索引。

　　在UPDATE、DELETE操作時(shí)，MySQL不僅鎖定WHERE條件掃描過的所有索引記錄，而且會鎖定相鄰的鍵值，即所謂的next-key locking。

　　例如，一個(gè)表db。tab_test，結(jié)構(gòu)如下：

　　id：主鍵;

　　state：狀態(tài);

　　time：時(shí)間;

　　索引：idx_1(state，time)

　　出現(xiàn)死鎖日志如下：

　　?***(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) (任務(wù)1的sql語句)

　　?***(1) WAITING FOR THIS LOCK TO BE GRANTED: (任務(wù)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) (任務(wù)2的sql語句)

　　?*** (2) HOLDS THE LOCK(S): (任務(wù)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: (任務(wù)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)

　　?(回滾了任務(wù)1，以解除死鎖)

　　原因分析：

　　當(dāng)“update tab_test set state=1064,time=now() where state=1061 and time date_sub(now(), INTERVAL 30 minute)”執(zhí)行時(shí)，MySQL會使用idx_1索引，因此首先鎖定相關(guān)的索引記錄，因?yàn)閕dx_1是非主鍵索引，為執(zhí)行該語句，MySQL還會鎖定主鍵索引。

　　假設(shè)“update tab_test set state=1067,time=now () where id in (9921180)”幾乎同時(shí)執(zhí)行時(shí)，本語句首先鎖定主鍵索引，由于需要更新state的值，所以還需要鎖定idx_1的某些索引記錄。

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

　　6、解決辦法

　　拆分第一條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(......);

　　關(guān)于MySQL死鎖問題的實(shí)例分析及解決方法就介紹到這里了，希望本次的介紹能夠?qū)δ兴斋@!

Mysql 官方文檔：http://dev.mysql.com/doc/refman/5.7/en/innodb-deadlock-example.html

您可能感興趣的文章:

mysql 數(shù)據(jù)庫死鎖原因及解決辦法
Mysql 數(shù)據(jù)庫死鎖過程分析(select for update)
簡單說明Oracle數(shù)據(jù)庫中對死鎖的查詢及解決方法
InnoDB數(shù)據(jù)庫死鎖問題處理
Mybatis update數(shù)據(jù)庫死鎖之獲取數(shù)據(jù)庫連接池等待
講解Oracle數(shù)據(jù)庫中結(jié)束死鎖進(jìn)程的一般方法
記一次公司倉庫數(shù)據(jù)庫服務(wù)器死鎖過程及解決辦法
查詢Sqlserver數(shù)據(jù)庫死鎖的一個(gè)存儲過程分享
MySQL數(shù)據(jù)庫之Purge死鎖問題解析
5分鐘快速了解數(shù)據(jù)庫死鎖產(chǎn)生的場景和解決方法

標(biāo)簽：衡水銅川仙桃蘭州湖南崇左黃山湘潭

巨人網(wǎng)絡(luò)通訊聲明：本文標(biāo)題《MySQL數(shù)據(jù)庫的一次死鎖實(shí)例分析》，本文關(guān)鍵詞；如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題，煩請?zhí)峁┫嚓P(guān)信息告之我們，我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò)，涉及言論、版權(quán)與本站無關(guān)。