MySQL死鎖問(wèn)題分析及解決方法實(shí)例詳解
MySQL死鎖問(wèn)題是很多程序員在項(xiàng)目開(kāi)發(fā)中常遇到的問(wèn)題，現(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í)鎖：開(kāi)銷(xiāo)小,加鎖快;不會(huì)出現(xiàn)死鎖;鎖定粒度大,發(fā)生鎖沖突的概率最高,并發(fā)度最低
行級(jí)鎖：開(kāi)銷(xiāo)大,加鎖慢;會(huì)出現(xiàn)死鎖;鎖定粒度最小,發(fā)生鎖沖突的概率最低,并發(fā)度也最高
頁(yè)面鎖：開(kāi)銷(xiāo)和加鎖時(shí)間界于表鎖和行鎖之間;會(huì)出現(xiàn)死鎖;鎖定粒度界于表鎖和行鎖之間,并發(fā)度一般
3、各種鎖的適用場(chǎng)景
表級(jí)鎖更適合于以查詢(xún)?yōu)橹?只有少量按索引條件更新數(shù)據(jù)的應(yīng)用,如Web應(yīng)用
行級(jí)鎖則更適合于有大量按索引條件并發(fā)更新數(shù)據(jù),同時(shí)又有并發(fā)查詢(xún)的應(yīng)用,如一些在線(xiàn)事務(wù)處理系統(tǒng)
4、死鎖
是指兩個(gè)或兩個(gè)以上的進(jìn)程在執(zhí)行過(guò)程中,因爭(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條件掃描過(guò)的所有索引記錄，而且會(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死鎖問(wèn)題得以解決！
相關(guān)文章
mysql 讓一個(gè)存儲(chǔ)過(guò)程定時(shí)作業(yè)的代碼
以下例子主要是實(shí)現(xiàn)簡(jiǎn)單的mysq 定時(shí)作業(yè)，需要的朋友可以參考下。2011-05-05
本文將介紹MySQL索引詳細(xì)使方法；需要的朋友可以參考下2012-11-11
MySQL數(shù)據(jù)庫(kù)學(xué)習(xí)之排序與單行處理函數(shù)詳解
這篇文章主要為大家詳細(xì)介紹一下MySQL數(shù)據(jù)庫(kù)中排序與單行處理函數(shù)的使用，文中的示例代碼講解詳細(xì)，對(duì)我們學(xué)習(xí)MySQL有一定幫助，需要的可以參考一下2022-07-07
淺析MySQL如何實(shí)現(xiàn)事務(wù)隔離
使用過(guò)關(guān)系型數(shù)據(jù)庫(kù)的，應(yīng)該都事務(wù)的概念有所了解，知道事務(wù)有 ACID 四個(gè)基本屬性：原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）和持久性（Durability），今天我們主要來(lái)理解一下事務(wù)的隔離性2021-06-06
命令行模式下備份、還原 MySQL 數(shù)據(jù)庫(kù)的語(yǔ)句小結(jié)
為了安全起見(jiàn)，需要經(jīng)常對(duì)數(shù)據(jù)庫(kù)作備份，或者還原,學(xué)會(huì)在命令行模式下備份、還原數(shù)據(jù)庫(kù)，還是很有必要2012-11-11
本文主要介紹了深入理解MySQL分區(qū)表的使用2024-03-03
MySQL臨時(shí)表在很多場(chǎng)景中都會(huì)用到，比如用戶(hù)自己創(chuàng)建的臨時(shí)表用于保存臨時(shí)數(shù)據(jù)，以及MySQL內(nèi)部在執(zhí)行復(fù)雜SQL時(shí)，需要借助臨時(shí)表進(jìn)行分組、排序、去重等操作，本文就來(lái)詳細(xì)的介紹一下MySQL內(nèi)部臨時(shí)表2021-10-10
Windows10系統(tǒng)下MySQL（8.0.37）安裝與配置教程
相信很多人都遇到過(guò)安裝Mysql的時(shí)候出現(xiàn)各種各樣的問(wèn)題,下面這篇文章主要給大家介紹了關(guān)于Windows10系統(tǒng)下MySQL（8.0.37）安裝與配置的相關(guān)資料,文中通過(guò)圖文介紹的非常詳細(xì),需要的朋友可以參考下2024-07-07
本文的主要目的是在?Windwos?上安裝?MySQL，以下內(nèi)容是源于?B站?-?MySQL數(shù)據(jù)庫(kù)入門(mén)到精通整理而來(lái),需要的朋友可以參考下2023-06-06
Mysql跨表更新 多表update sql語(yǔ)句總結(jié)
Mysql跨表更新一直是大家所關(guān)心的話(huà)題，本文介紹mysql多表 update在實(shí)踐中幾種不同的寫(xiě)法，需要的朋友可以參考下2012-12-12