一、MySQL鎖類型
1. MySQL常用存儲引擎的鎖機制
MyISAM和MEMORY采用表級鎖(table-level locking)
BDB采用頁面鎖(page-level locking)或表級鎖，默認為頁面鎖
InnoDB支持行級鎖(row-level locking)和表級鎖,默認為行級鎖
2. 各種鎖特點
表級鎖：開銷小,加鎖快;不會出現死鎖;鎖定粒度大,發生鎖沖突的概率最高,並發度最低
行級鎖：開銷大,加鎖慢;會出現死鎖;鎖定粒度最小,發生鎖沖突的概率最低,並發度也最高
頁面鎖：開銷和加鎖時間界於表鎖和行鎖之間;會出現死鎖;鎖定粒度界於表鎖和行鎖之間,並發度一般
3. 各種鎖的適用場景
表級鎖更適合於以查詢為主,只有少量按索引條件更新數據的應用,如Web應用
行級鎖則更適合於有大量按索引條件並發更新數據,同時又有並發查詢的應用,如一些在線事務處理系統。
二、 MySQL死鎖產生原因
所謂死鎖<DeadLock>：是指兩個或兩個以上的進程在執行過程中,因爭奪資源而造成的一種互相等待的現象,若無外力作用，它們都將無法推進下去.此時稱系統處於死鎖狀態或系統產生了死鎖，這些永遠在互相等待的進程稱為死鎖進程。表級鎖不會產生死鎖.所以解決死鎖主要還是針對於最常用的InnoDB。
死鎖的關鍵在於：兩個(或以上)的Session加鎖的順序不一致。
那么對應的解決死鎖問題的關鍵就是：讓不同的session加鎖有次序。
三、 MySQL死鎖舉例分析
案例一：
在MySQL中，行級鎖並不是直接鎖記錄，而是鎖索引。索引分為主鍵索引和非主鍵索引兩種，如果一條sql語句操作了主鍵索引，MySQL就會鎖定這條主鍵索引；如果一條語句操作了非主鍵索引，MySQL會先鎖定該非主鍵索引，再鎖定相關的主鍵索引。在UPDATE、DELETE操作時，MySQL不僅鎖定WHERE條件掃描過的所有索引記錄，而且會鎖定相鄰的鍵值，即所謂的next-key locking。
例如，一個表db.tab_test，結構如下：
id：主鍵；state：狀態；time：時間；索引：idx_1 (state, time)
出現死鎖日志如下：
***(1) TRANSACTION: TRANSACTION 0 677833455, ACTIVE 0 sec, process no 11393, OS thread id 278546 starting index readmysql 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 updateupdate tab_test set state=1064,time=now() where state=1061 and time < date_sub(now(), INTERVAL 30 minute) （任務1的sql語句） ***(1) WAITING FOR THIS LOCK TO BE GRANTED: （任務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) （任務2的sql語句） *** (2) HOLDS THE LOCK(S): （任務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: （任務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) （回滾了任務1，以解除死鎖）
原因分析：
當“update tab_test set state=1064,time=now() where state=1061 and time < date_sub(now(), INTERVAL 30 minute)”執行時，MySQL會使用idx_1索引，因此首先鎖定相關的索引記錄，因為idx_1是非主鍵索引，為執行該語句，MySQL還會鎖定主鍵索引。
假設“update tab_test set state=1067,time=now () where id in (9921180)”幾乎同時執行時，本語句首先鎖定主鍵索引，由於需要更新state的值，所以還需要鎖定idx_1的某些索引記錄。
這樣第一條語句鎖定了idx_1的記錄，等待主鍵索引，而第二條語句則鎖定了主鍵索引記錄，而等待idx_1的記錄，這樣死鎖就產生了。
解決辦法
拆分第一條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死鎖問題得以解決！
案例二：
在開發中，經常會做這類的判斷需求：根據字段值查詢（有索引），如果不存在，則插入；否則更新。
以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語句對於主鍵來說，插入的行不管有沒有存在，都會只有行鎖。
案例三：
一般的情況，兩個session分別通過一個sql持有一把鎖，然后互相訪問對方加鎖的數據產生死鎖。
案例四：
兩個單條的sql語句涉及到的加鎖數據相同，但是加鎖順序不同，導致了死鎖。
四、 MySQL死鎖總結
1. 死鎖預防策略
InnoDB引擎內部(或者說是所有的數據庫內部)，有多種鎖類型：事務鎖(行鎖、表鎖)，Mutex(保護內部的共享變量操作)、RWLock(又稱之為Latch，保護內部的頁面讀取與修改)。
InnoDB每個頁面為16K，讀取一個頁面時，需要對頁面加S鎖，更新一個頁面時，需要對頁面加上X鎖。任何情況下，操作一個頁面，都會對頁面加鎖，頁面鎖加上之后，頁面內存儲的索引記錄才不會被並發修改。
因此，為了修改一條記錄，InnoDB內部如何處理：根據給定的查詢條件，找到對應的記錄所在頁面；對頁面加上X鎖(RWLock)，然后在頁面內尋找滿足條件的記錄；在持有頁面鎖的情況下，對滿足條件的記錄加事務鎖(行鎖：
根據記錄是否滿足查詢條件，記錄是否已經被刪除，分別對應於上面提到的3種加鎖策略之一)；
死鎖預防策略：相對於事務鎖，頁面鎖是一個短期持有的鎖，而事務鎖(行鎖、表鎖)是長期持有的鎖。因此，為了防止頁面鎖與事務鎖之間產生死鎖。
InnoDB做了死鎖預防的策略：持有事務鎖(行鎖、表鎖)，可以等待獲取頁面鎖；但反之，持有頁面鎖，不能等待持有事務鎖。根據死鎖預防策略，在持有頁面鎖，加行鎖的時候，如果行鎖需要等待。則釋放頁面鎖，然后等待行鎖。此時，行鎖獲取沒有任何鎖保護，因此加上行鎖之后，記錄可能已經被並發修改。
因此，此時要重新加回頁面鎖，重新判斷記錄的狀態，重新在頁面鎖的保護下，對記錄加鎖。如果此時記錄未被並發修改，那么第二次加鎖能夠很快完成，因為已經持有了相同模式的鎖。
但是，如果記錄已經被並發修改，那么，就有可能導致本文前面提到的死鎖問題。以上的InnoDB死鎖預防處理邏輯，對應的函數，是row0sel.c::row_search_for_mysql()。
感興趣的朋友，可以跟蹤調試下這個函數的處理流程，很復雜，但是集中了InnoDB的精髓。
2. 死鎖產生的前提
Delete操作，針對的是唯一索引上的等值查詢的刪除；(范圍下的刪除，也會產生死鎖，但是死鎖的場景，跟本文分析的場景，有所不同)。
少有3個(或以上)的並發刪除操作；
並發刪除操作，有可能刪除到同一條記錄，並且保證刪除的記錄一定存在；
事務的隔離級別設置為Repeatable Read，同時未設置innodb_locks_unsafe_for_binlog參數(此參數默認為FALSE)；(Read Committed隔離級別，由於不會加Gap鎖，不會有next key，因此也不會產生死鎖)；
使用的是InnoDB存儲引擎；(廢話！MyISAM引擎根本就沒有行鎖)。