共計 3292 個字符，預計需要花費 9 分鐘才能閱讀完成。
這篇文章主要介紹了 MySQL 并發時經典常見的死鎖原因有哪些，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓丸趣 TV 小編帶著大家一起了解一下。
1、mysql 都有什么鎖？
MySQL 有三種鎖的級別：頁級、表級、行級。
表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖沖突的概率最高, 并發度最低。
行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖沖突的概率最低, 并發度也最高。
頁面鎖：開銷和加鎖時間界于表鎖和行鎖之間；會出現死鎖；鎖定粒度界于表鎖和行鎖之間，并發度一般
算法：
next KeyLocks 鎖，同時鎖住記錄(數據)，并且鎖住記錄前面的 Gap
Gap 鎖，不鎖記錄，僅僅記錄前面的 Gap
Recordlock 鎖（鎖數據，不鎖 Gap）
所以其實 Next-KeyLocks=Gap 鎖 + Recordlock 鎖
2. 什么情況下會造成死鎖
所謂死鎖 DeadLock : 是指兩個或兩個以上的進程在執行過程中,
因爭奪資源而造成的一種互相等待的現象, 若無外力作用, 它們都將無法推進下去.
此時稱系統處于死鎖狀態或系統產生了死鎖, 這些永遠在互相等竺的進程稱為死鎖進程.
表級鎖不會產生死鎖. 所以解決死鎖主要還是針對于最常用的 InnoDB.
死鎖的關鍵在于：兩個 (或以上) 的 Session 加鎖的順序不一致。
那么對應的解決死鎖問題的關鍵就是：讓不同的 session 加鎖有次序
3. 一些常見的死鎖案例
案例一：
需求：將投資的錢拆成幾份隨機分配給借款人。
起初業務程序思路是這樣的：
投資人投資后，將金額隨機分為幾份，然后隨機從借款人表里面選幾個，然后通過一條條 select for update 去更新借款人表里面的余額等。
抽象出來就是一個 session 通過 for 循環會有幾條如下的語句：
Select * from xxx where id= 隨機 id for update基本來說，程序開啟后不一會就死鎖。
這可以是說最經典的死鎖情形了。
例如兩個用戶同時投資，A 用戶金額隨機分為 2 份，分給借款人 1，2
B 用戶金額隨機分為 2 份，分給借款人 2，1
由于加鎖的順序不一樣，死鎖當然很快就出現了。
對于這個問題的改進很簡單，直接把所有分配到的借款人直接一次鎖住就行了。
Select * from xxx where id in (xx,xx,xx) for update
在 in 里面的列表值 mysql 是會自動從小到大排序，加鎖也是一條條從小到大加的鎖
例如（以下會話 id 為主鍵）：Session1:
mysql select * from t3 where id in (8,9) for update;
+----+--------+------+---------------------+
| id | course | name | ctime |
+----+--------+------+---------------------+
| 8 | WA | f | 2016-03-02 11:36:30 |
| 9 | JX | f | 2016-03-01 11:36:30 |
+----+--------+------+---------------------+
2 rows in set (0.04 sec)
Session2:
select * from t3 where id in (10,8,5) for update;
鎖等待中……
其實這個時候 id=10 這條記錄沒有被鎖住的，但 id= 5 的記錄已經被鎖住了，鎖的等待在 id= 8 的這里。Session3:
mysql select * from t3 where id=5 for update;
Session4:
mysql select * from t3 where id=10 for update;
+----+--------+------+---------------------+
| id | course | name | ctime |
+----+--------+------+---------------------+
| 10 | JB | g | 2016-03-10 11:45:05 |
+----+--------+------+---------------------+
1 row in set (0.00 sec)
在其它 session 中 id= 5 是加不了鎖的，但是 id=10 是可以加上鎖的。案例 2：
在開發中，經常會做這類的判斷需求：根據字段值查詢（有索引），如果不存在，則插入；否則更新。
以 id 為主鍵為例，目前還沒有 id=22 的行
Session1:
select * from t3 where id=22 for update;
Empty set (0.00 sec)
session2:
select * from t3 where id=23 for update;
Empty set (0.00 sec)
Session1:
insert into t3 values(22, ac , a ,now());
鎖等待中……
Session2:
insert into t3 values(23, bc , b ,now());
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction當對存在的行進行鎖的時候(主鍵)，mysql 就只有行鎖。
當對未存在的行進行鎖的時候(即使條件為主鍵)，mysql 是會鎖住一段范圍（有 gap 鎖）
鎖住的范圍為：
(無窮小或小于表中鎖住 id 的最大值，無窮大或大于表中鎖住 id 的最小值)
如：如果表中目前有已有的 id 為（11，12）
那么就鎖住（12，無窮大）
如果表中目前已有的 id 為（11，30）
那么就鎖住（11，30）
對于這種死鎖的解決辦法是：
insert into t3(xx,xx) on duplicate key update `xx`= XX
用 mysql 特有的語法來解決此問題。因為 insert 語句對于主鍵來說，插入的行不管有沒有存在，都會只有行鎖。
案例 3：
直接上情景：
mysql select * from t3 where id=9 for update;
+----+--------+------+---------------------+
| id | course | name | ctime |
+----+--------+------+---------------------+
| 9 | JX | f | 2016-03-01 11:36:30 |
+----+--------+------+---------------------+
1 row in set (0.00 sec)
Session2:
mysql select * from t3 where id 20 for update;
Session1:
mysql insert into t3 values(7, ae , a ,now());
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction這個跟案例一其它是差不多的情況，只是 session1 不按常理出牌了，
Session2 在等待 Session1 的 id= 9 的鎖，session2 又持了 1 到 8 的鎖（注意 9 到 19 的范圍并沒有被 session2 鎖住），最后，session1 在插入新行時又得等待 session2, 故死鎖發生了。
這種一般是在業務需求中基本不會出現，因為你鎖住了 id=9，卻又想插入 id= 7 的行，這就有點跳了，當然肯定也有解決的方法，那就是重理業務需求，避免這樣的寫法。
感謝你能夠認真閱讀完這篇文章，希望丸趣 TV 小編分享的“MySQL 并發時經典常見的死鎖原因有哪些”這篇文章對大家有幫助，同時也希望大家多多支持丸趣 TV，關注丸趣 TV 行業資訊頻道，更多相關知識等著你來學習!
