mysql有三種鎖的級別：頁級、表級、行級。
表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖衝突的概率最高,併發度最低。
行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖衝突的概率最低,併發度也最高。
頁面鎖：開銷和加鎖時間界於表鎖和行鎖之間；會出現死鎖；鎖定粒度界於表鎖和行鎖之間，併發度一般
演算法：
next keylocks鎖，同時鎖住記錄(資料)，並且鎖住記錄前面的gap （gap就是索引樹中插入新記錄的空隙）
gap鎖，不鎖記錄，僅僅記錄前面的gap
recordlock鎖（鎖資料，不鎖gap）
所以其實 next-keylocks=gap鎖+ recordlock鎖
所謂死鎖: 是指兩個或兩個以上的程序在執行過程中,
因爭奪資源而造成的一種互相等待的現象,若無外力作用,它們都將無法推進下去.
此時稱系統處於死鎖狀態或系統產生了死鎖,這些永遠在互相等竺的程序稱為死鎖程序.
表級鎖不會產生死鎖.所以解決死鎖主要還是針對於最常用的innodb.
死鎖的關鍵在於：兩個(或以上)的session加鎖的順序不一致。
那麼對應的解決死鎖問題的關鍵就是：讓不同的session加鎖有次序
案例一：
需求：將投資的錢拆成幾份隨機分配給借款人。
起初業務程式思路是這樣的：
投資人投資後，將金額隨機分為幾份，然後隨機從借款人表裡面選幾個，然後通過一條條select for update 去更新借款人表裡面的餘額等。
抽象出來就是乙個session通過for迴圈會有幾條如下的語句：
select * from *** where id='隨機id' for update這可以是說最經典的死鎖情形了。
例如兩個使用者同時投資，a使用者金額隨機分為2份，分給借款人1，2
b使用者金額隨機分為2份，分給借款人2，1
由於加鎖的順序不一樣，死鎖當然很快就出現了。
對於這個問題的改進很簡單，直接把所有分配到的借款人直接一次鎖住就行了。
select * from *** where id in (xx,xx,xx) for update複製**
例如（以下會話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)
複製**
案例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';案例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的行，這就有點跳了，當然肯定也有解決的方法，那就是重理業務需求，避免這樣的寫法。
資料庫死鎖
1.死鎖的概念 死鎖是程序死鎖的簡稱，是由dijkstra於1965年研究銀行家演算法時首先提出來的。它是計算機作業系統乃至併發程式設計中最難處理的問題之一。實際上，死鎖問題不僅在計算機系統中存在，在我們日常生活中它也廣泛存在。我們先看看這樣乙個生活中的例子 在一條河上有一座橋，橋面較窄，只能容納一...
資料庫死鎖
資料庫在進行insert，update，delete這些更新操作的時候為了保證資料一致性都會使用排他鎖。乙個事務裡進行update操作，在事務結束之前 commit or rollback 排他鎖不會被釋放。因此在乙個事務裡update多條資料的時候執行順序就尤為重要，兩個併發事務中更新操作的執行順...
資料庫死鎖
死鎖 所謂死鎖 是指兩個或兩個以上的程序在執行過程中,因爭奪資源而造成的一種互相等待的現象,若無外力作用,它們都將無法推進下去.此時稱系統處於死鎖狀態或系統產生了死鎖,這些永遠在互相等待的程序稱為死鎖程序 由於資源占用是互斥的，當某個程序提出申請資源後，使得有關程序在無外力協助下，永遠分配不到必需的...