MySQL都有什么鎖？
MySQL有三種鎖的級別：頁級、表級、行級。
表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖沖突的概率最高,並發度最低。
行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖沖突的概率最低,並發度也最高。
頁面鎖：開銷和加鎖時間界於表鎖和行鎖之間；會出現死鎖；鎖定粒度界於表鎖和行鎖之間，並發度一般
算法：
next KeyLocks鎖，同時鎖住記錄(數據)，並且鎖住記錄前面的Gap
Gap鎖，不鎖記錄，僅僅記錄前面的Gap
Recordlock鎖（鎖數據，不鎖Gap）
所以其實 Next-KeyLocks=Gap鎖+ Recordlock鎖
什么情況下會造成死鎖？
所謂死鎖
:
是指兩個或兩個以上的進程在執行過程中，因爭奪資源而造成的一種互相等待的現象,若無外力作用,它們都將無法推進下去，此時稱系統處於死鎖狀態或系統產生了死鎖,這些永遠在互相等竺的進程稱為死鎖進程，表級鎖不會產生死鎖.所以解決死鎖主要還是針對於最常用的InnoDB。
死鎖的關鍵
兩個(或以上)的Session加鎖的順序不一致。那么對應的解決死鎖問題的關鍵就是：讓不同的session加鎖有次序
一些常見的死鎖案例
案例一：
需求：將投資的錢拆成幾份隨機分配給借款人。
起初業務程序思路是這樣的：投資人投資后，將金額隨機分為幾份，然后隨機從借款人表里面選幾個，然后通過一條條 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是會自動從小到大排序，加鎖也是一條條從小到大加的鎖
案例
Session1
以下會話id為主鍵
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
在開發中，經常會做這類的判斷需求：根據字段值查詢（有索引），如果不存在，則插入；否則更新。