本文主要給大家介紹MySQL出現(xiàn)死鎖的原因及解決方案，文章內(nèi)容都是筆者用心摘選和編輯的，具有一定的針對性，對大家的參考意義還是比較大的，下面跟筆者一起了解下mysql出現(xiàn)死鎖的原因及解決方案吧。

1. mysql都有什么鎖

MySQL有三種鎖的級別：頁級、表級、行級，內(nèi)存級（latch）。

讓客戶滿意是我們工作的目標，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領域值得信任、有價值的長期合作伙伴，公司提供的服務項目有：域名申請、雅安服務器托管、營銷軟件、網(wǎng)站建設、云霄網(wǎng)站維護、網(wǎng)站推廣。

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

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

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

算法：

next KeyLocks鎖，同時鎖住記錄(數(shù)據(jù))，并且鎖住記錄前面的Gap

Gap鎖，不鎖記錄，僅僅記錄前面的Gap

Recordlock鎖（鎖數(shù)據(jù)，不鎖Gap）

所以其實 Next-KeyLocks=Gap鎖+ Recordlock鎖

1. 什么情況下會造成死鎖

所謂死鎖 DeadLock 是指兩個或兩個以上的進程在執(zhí)行過程中,
因爭奪資源而造成的一種互相等待的現(xiàn)象,若無外力作用,它們都將無法推進下去.
此時稱系統(tǒng)處于死鎖狀態(tài)或系統(tǒng)產(chǎn)生了死鎖,這些永遠在互相等竺的進程稱為死鎖進程.
表級鎖不會產(chǎn)生死鎖.所以解決死鎖主要還是針對于最常用的InnoDB.

死鎖的關鍵在于：兩個(或以上)的Session加鎖的順序不一致。

那么對應的解決死鎖問題的關鍵就是：讓不同的session加鎖有次序

4，下面就簡單來重現(xiàn)一下死鎖：

死鎖重現(xiàn)：
事務A:
root@test 16:01>select connection_id();
+-----------------+
| connection_id() |
+-----------------+
|           47274 |
+-----------------+
1 row in set (0.01 sec)

root@test 16:02>set autocommit =0;
Query OK, 0 rows affected (0.00 sec)

root@test 16:02>select * from t where id =1 for update;
+----+
| id |
+----+
|  1 |
+----+
1 row in set (0.00 sec)

root@test 16:02>select * from t where id =2 for update;
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
root@test 16:03>

事務B：
root@test 16:02>select connection_id();
+-----------------+
| connection_id() |
+-----------------+
|           47272 |
+-----------------+
1 row in set (0.00 sec)

root@test 16:02>set autocommit =0;
Query OK, 0 rows affected (0.00 sec)

root@test 16:02>select * from t where id =2 for update;
+----+
| id |
+----+
|  2 |
+----+
1 row in set (0.00 sec)

root@test 16:03>select * from t where id =1 for update;
+----+
| id |
+----+
|  1 |
+----+
1 row in set (5.53 sec)

===========================================

死鎖信息：

LATEST DETECTED DEADLOCK

2018-10-19 16:03:14 7f9612b6d700
(1) TRANSACTION:
TRANSACTION 870600, ACTIVE 11 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 360, 2 row lock(s)
MySQL thread id 47272, OS thread handle 0x7f9612e38700, query id 1112421 127.0.0.1 root statistics
select  from t where id =1 for update
** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 330 page no 3 n bits 72 index PRIMARY of table test.t trx id 870600 lock_mode X locks rec but not gap waiting
(2) TRANSACTION:
TRANSACTION 870599, ACTIVE 22 sec starting index read
mysql tables in use 1, locked 1
3 lock struct(s), heap size 360, 2 row lock(s)
MySQL thread id 47274, OS thread handle 0x7f9612b6d700, query id 1112422 127.0.0.1 root statistics
select * from t where id =2 for update
(2) HOLDS THE LOCK(S):
RECORD LOCKS space id 330 page no 3 n bits 72 index PRIMARY of table test.t trx id 870599 lock_mode X locks rec but not gap
(2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 330 page no 3 n bits 72 index PRIMARY of table test.t trx id 870599 lock_mode X locks rec but not gap waiting
*** WE ROLL BACK TRANSACTION (2)

5分析：
1，這上面是顯示是事務產(chǎn)生死鎖的sql并打印出相應所持和等待的鎖
2，上面的信息并沒有輸出事務死鎖之前的sql，所以可以直接堆出兩個事務執(zhí)行的sql使他們相互持有了對方等待的鎖
3，造成死鎖是必然的，慢sql和不合理的業(yè)務的邏輯是造成死鎖過多的主要原因

重要的事情說三遍：優(yōu)化sql，優(yōu)化業(yè)務，優(yōu)化邏輯

看完以上關于mysql出現(xiàn)死鎖的原因及解決方案，很多讀者朋友肯定多少有一定的了解，如需獲取更多的行業(yè)知識信息 ，可以持續(xù)關注我們的行業(yè)資訊欄目的。

本文名稱：mysql出現(xiàn)死鎖的原因及解決方案
鏈接分享：http://www.rwnh.cn/article38/jipipp.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供企業(yè)網(wǎng)站制作、網(wǎng)站建設、移動網(wǎng)站建設、云服務器、響應式網(wǎng)站、關鍵詞優(yōu)化

廣告

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