MySQL死鎖問題的分析及解決方法

這篇文章主要講解了“MySQL死鎖問題的分析及解決方法”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“MySQL死鎖問題的分析及解決方法”吧！

成都服務(wù)器托管，創(chuàng)新互聯(lián)建站提供包括服務(wù)器租用、南充服務(wù)器托管、帶寬租用、云主機(jī)、機(jī)柜租用、主機(jī)租用托管、CDN網(wǎng)站加速、域名申請(qǐng)等業(yè)務(wù)的一體化完整服務(wù)。電話咨詢：028-86922220

MySQL死鎖問題是很多程序員在項(xiàng)目開發(fā)中常遇到的問題，現(xiàn)就MySQL死鎖及解決方法詳解如下：

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

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

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

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

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

表級(jí)鎖：開銷小,加鎖快;不會(huì)出現(xiàn)死鎖;鎖定粒度大,發(fā)生鎖沖突的概率***,并發(fā)度***

行級(jí)鎖：開銷大,加鎖慢;會(huì)出現(xiàn)死鎖;鎖定粒度最小,發(fā)生鎖沖突的概率***,并發(fā)度也***

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

3、各種鎖的適用場(chǎng)景

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

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

4、死鎖

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

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

5、死鎖舉例分析

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

在UPDATE、DELETE操作時(shí)，MySQL不僅鎖定WHERE條件掃描過的所有索引記錄，而且會(huì)鎖定相鄰的鍵值，即所謂的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語(yǔ)句）  ***(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語(yǔ)句）  *** (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會(huì)使用idx_1索引，因此首先鎖定相關(guān)的索引記錄，因?yàn)閕dx_1是非主鍵索引，為執(zhí)行該語(yǔ)句，MySQL還會(huì)鎖定主鍵索引。

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

這樣***條語(yǔ)句鎖定了idx_1的記錄，等待主鍵索引，而第二條語(yǔ)句則鎖定了主鍵索引記錄，而等待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(......);

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

感謝各位的閱讀，以上就是“MySQL死鎖問題的分析及解決方法”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)MySQL死鎖問題的分析及解決方法這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！

本文標(biāo)題：MySQL死鎖問題的分析及解決方法
轉(zhuǎn)載源于：http://www.muchs.cn/article24/iidhce.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)網(wǎng)站制作、服務(wù)器托管、全網(wǎng)營(yíng)銷推廣、關(guān)鍵詞優(yōu)化、小程序開發(fā)、App設(shè)計(jì)

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源：創(chuàng)新互聯(lián)

猜你還喜歡下面的內(nèi)容