關於死鎖
MyISAM表鎖是deadlock free的，這是因為MyISAM總是一次獲得所需的全部鎖，要么全部滿足，要么等待，因此不會出現死鎖。但在InnoDB中，除單個SQL組成的事務外，鎖是逐步獲得的，這就決定了在InnoDB中發生死鎖是可能的。如表20-17所示的就是一個發生死鎖的例子。
表20-17 InnoDB存儲引擎中的死鎖例子
| session_1 |
session_2 |
| mysql> set autocommit = 0; Query OK, 0 rows affected (0.00 sec) mysql> select * from table_1 where where id=1 for update; ... 做一些其他處理... |
mysql> set autocommit = 0; Query OK, 0 rows affected (0.00 sec) mysql> select * from table_2 where id=1 for update; ... |
| select * from table_2 where id =1 for update; 因session_2已取得排他鎖，等待 |
做一些其他處理... |
| mysql> select * from table_1 where where id=1 for update; 死鎖 |
在上面的例子中，兩個事務都需要獲得對方持有的排他鎖才能繼續完成事務，這種循環鎖等待就是典型的死鎖。
發生死鎖后，InnoDB一般都能自動檢測到，並使一個事務釋放鎖並回退，另一個事務獲得鎖，繼續完成事務。但在涉及外部鎖，或涉及表鎖的情況 下，InnoDB並不能完全自動檢測到死鎖，這需要通過設置鎖等待超時參數 innodb_lock_wait_timeout來解決。需要說明的是，這個參數並不是只用來解決死鎖問題，在並發訪問比較高的情況下，如果大量事務因無法立即獲得所需的鎖而掛起，會占用大量計算機資源，造成嚴重性能問題，甚至拖跨數據庫。我們通過設置合適的鎖等待超時閾值，可以避免這種情況發生。
通常來說，死鎖都是應用設計的問題，通過調整業務流程、數據庫對象設計、事務大小，以及訪問數據庫的SQL語句，絕大部分死鎖都可以避免。下面就通過實例來介紹幾種避免死鎖的常用方法。
1）在應用中，如果不同的程序會並發存取多個表，應盡量約定以相同的順序來訪問表，這樣可以大大降低產生死鎖的機會。在下面的例子中，由於兩個session訪問兩個表的順序不同，發生死鎖的機會就非常高！但如果以相同的順序來訪問，死鎖就可以避免。
表20-18 InnoDB存儲引擎中表順序造成的死鎖例子
| session_1 |
session_2 |
| mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec) |
mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec) |
| mysql> select first_name,last_name from actor where actor_id = 1 for update; +------------+-----------+ | first_name | last_name | +------------+-----------+ | PENELOPE | GUINESS | +------------+-----------+ 1 row in set (0.00 sec) |
|
| mysql> insert into country (country_id,country) values(110,'Test'); Query OK, 1 row affected (0.00 sec) |
|
| mysql> insert into country (country_id,country) values(110,'Test'); 等待 |
|
| mysql> select first_name,last_name from actor where actor_id = 1 for update; +------------+-----------+ | first_name | last_name | +------------+-----------+ | PENELOPE | GUINESS | +------------+-----------+ 1 row in set (0.00 sec) |
|
| mysql> insert into country (country_id,country) values(110,'Test'); ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction |
2）在程序以批量方式處理數據的時候，如果事先對數據排序，保證每個線程按固定的順序來處理記錄，也可以大大降低出現死鎖的可能。
表20-19 InnoDB存儲引擎中表數據操作順序不一致造成的死鎖例子
| session_1 |
session_2 |
| mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec) |
mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec) |
| mysql> select first_name,last_name from actor where actor_id = 1 for update; +------------+-----------+ | first_name | last_name | +------------+-----------+ | PENELOPE | GUINESS | +------------+-----------+ 1 row in set (0.00 sec) |
|
| mysql> select first_name,last_name from actor where actor_id = 3 for update; +------------+-----------+ | first_name | last_name | +------------+-----------+ | ED | CHASE | +------------+-----------+ 1 row in set (0.00 sec) |
|
| mysql> select first_name,last_name from actor where actor_id = 3 for update; 等待 |
|
| mysql> select first_name,last_name from actor where actor_id = 1 for update; ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction |
|
| mysql> select first_name,last_name from actor where actor_id = 3 for update; +------------+-----------+ | first_name | last_name | +------------+-----------+ | ED | CHASE | +------------+-----------+ 1 row in set (4.71 sec) |
3）在事務中，如果要更新記錄，應該直接申請足夠級別的鎖，即排他鎖，而不應先申請共享鎖，更新時再申請排他鎖，因為當用戶申請排他鎖時，其他事務可能又已經獲得了相同記錄的共享鎖，從而造成鎖沖突，甚至死鎖。
4）前面講過，在REPEATABLE-READ隔離級別下，如果兩個線程同時對相同條件記錄用SELECT...FOR UPDATE加排他鎖，在沒有符合該條件記錄情況下，兩個線程都會加鎖成功。程序發現記錄尚不存在，就試圖插入一條新記錄，如果兩個線程都這么做，就會出 現死鎖。這種情況下，將隔離級別改成READ COMMITTED，就可避免問題，如表20-20所示。
表20-20 InnoDB存儲引擎中隔離級別引起的死鎖例子1
| session_1 |
session_2 |
| mysql> select @@tx_isolation; +-----------------+ | @@tx_isolation | +-----------------+ | REPEATABLE-READ | +-----------------+ 1 row in set (0.00 sec) mysql> set autocommit = 0; Query OK, 0 rows affected (0.00 sec) |
mysql> select @@tx_isolation; +-----------------+ | @@tx_isolation | +-----------------+ | REPEATABLE-READ | +-----------------+ 1 row in set (0.00 sec) mysql> set autocommit = 0; Query OK, 0 rows affected (0.00 sec) |
| 當前session對不存在的記錄加for update的鎖： mysql> select actor_id,first_name,last_name from actor where actor_id = 201 for update; Empty set (0.00 sec) |
|
| 其他session也可以對不存在的記錄加for update的鎖： mysql> select actor_id,first_name,last_name from actor where actor_id = 201 for update; Empty set (0.00 sec) |
|
| 因為其他session也對該記錄加了鎖，所以當前的插入會等待： mysql> insert into actor (actor_id , first_name , last_name) values(201,'Lisa','Tom'); 等待 |
|
| 因為其他session已經對記錄進行了更新，這時候再插入記錄就會提示死鎖並退出： mysql> insert into actor (actor_id, first_name , last_name) values(201,'Lisa','Tom'); ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction |
|
| 由於其他session已經退出，當前session可以獲得鎖並成功插入記錄： mysql> insert into actor (actor_id , first_name , last_name) values(201,'Lisa','Tom'); Query OK, 1 row affected (13.35 sec) |
5）當隔離級別為READ COMMITTED時，如果兩個線程都先執行SELECT...FOR UPDATE，判斷是否存在符合條件的記錄，如果沒有，就插入記錄。此時，只有一個線程能插入成功，另一個線程會出現鎖等待，當第1個線程提交后，第2個 線程會因主鍵重出錯，但雖然這個線程出錯了，卻會獲得一個排他鎖！這時如果有第3個線程又來申請排他鎖，也會出現死鎖。
對於這種情況，可以直接做插入操作，然后再捕獲主鍵重異常，或者在遇到主鍵重錯誤時，總是執行ROLLBACK釋放獲得的排他鎖，如表20-21所示。
表20-21 InnoDB存儲引擎中隔離級別引起的死鎖例子2
| session_1 |
session_2 |
session_3 |
| mysql> select @@tx_isolation; +----------------+ | @@tx_isolation | +----------------+ | READ-COMMITTED | +----------------+ 1 row in set (0.00 sec) mysql> set autocommit=0; Query OK, 0 rows affected (0.01 sec) |
mysql> select @@tx_isolation; +----------------+ | @@tx_isolation | +----------------+ | READ-COMMITTED | +----------------+ 1 row in set (0.00 sec) mysql> set autocommit=0; Query OK, 0 rows affected (0.01 sec) |
mysql> select @@tx_isolation; +----------------+ | @@tx_isolation | +----------------+ | READ-COMMITTED | +----------------+ 1 row in set (0.00 sec) mysql> set autocommit=0; Query OK, 0 rows affected (0.01 sec) |
| Session_1獲得for update的共享鎖： mysql> select actor_id, first_name,last_name from actor where actor_id = 201 for update; Empty set (0.00 sec) |
由於記錄不存在，session_2也可以獲得for update的共享鎖： mysql> select actor_id, first_name,last_name from actor where actor_id = 201 for update; Empty set (0.00 sec) |
|
| Session_1可以成功插入記錄： mysql> insert into actor (actor_id,first_name,last_name) values(201,'Lisa','Tom'); Query OK, 1 row affected (0.00 sec) |
||
| Session_2插入申請等待獲得鎖： mysql> insert into actor (actor_id,first_name,last_name) values(201,'Lisa','Tom'); 等待 |
||
| Session_1成功提交： mysql> commit; Query OK, 0 rows affected (0.04 sec) |
||
| Session_2獲得鎖，發現插入記錄主鍵重，這個時候拋出了異常，但是並沒有釋放共享鎖： mysql> insert into actor (actor_id,first_name,last_name) values(201,'Lisa','Tom'); ERROR 1062 (23000): Duplicate entry '201' for key 'PRIMARY' |
||
| Session_3申請獲得共享鎖，因為session_2已經鎖定該記錄，所以session_3需要等待： mysql> select actor_id, first_name,last_name from actor where actor_id = 201 for update; 等待 |
||
| 這個時候，如果session_2直接對記錄進行更新操作，則會拋出死鎖的異常： mysql> update actor set last_name='Lan' where actor_id = 201; ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction |
||
| Session_2釋放鎖后，session_3獲得鎖： mysql> select first_name, last_name from actor where actor_id = 201 for update; +------------+-----------+ | first_name | last_name | +------------+-----------+ | Lisa | Tom | +------------+-----------+ 1 row in set (31.12 sec) |
盡管通過上面介紹的設計和SQL優化等措施，可以大大減少死鎖，但死鎖很難完全避免。因此，在程序設計中總是捕獲並處理死鎖異常是一個很好的編程習慣。
如果出現死鎖，可以用SHOW INNODB STATUS命令來確定最后一個死鎖產生的原因。返回結果中包括死鎖相關事務的詳細信息，如引發死鎖的SQL語句，事務已經獲得的鎖，正在等待什么鎖，以及被回滾的事務等。據此可以分析死鎖產生的原因和改進措施。
小結
對於MyISAM的表鎖，主要討論了以下幾點：
（1）共享讀鎖（S）之間是兼容的，但共享讀鎖（S）與排他寫鎖（X）之間，以及排他寫鎖（X）之間是互斥的，也就是說讀和寫是串行的。
（2）在一定條件下，MyISAM允許查詢和插入並發執行，我們可以利用這一點來解決應用中對同一表查詢和插入的鎖爭用問題。
（3）MyISAM默認的鎖調度機制是寫優先，這並不一定適合所有應用，用戶可以通過設置LOW_PRIORITY_UPDATES參數，或在INSERT、UPDATE、DELETE語句中指定LOW_PRIORITY選項來調節讀寫鎖的爭用。
（4）由於表鎖的鎖定粒度大，讀寫之間又是串行的，因此，如果更新操作較多，MyISAM表可能會出現嚴重的鎖等待，可以考慮采用InnoDB表來減少鎖沖突。
對於InnoDB表，本章主要討論了以下幾項內容：
InnoDB的行鎖是基於鎖引實現的，如果不通過索引訪問數據，InnoDB會使用表鎖。
介紹了InnoDB間隙鎖（Next-key)機制，以及InnoDB使用間隙鎖的原因。
在不同的隔離級別下，InnoDB的鎖機制和一致性讀策略不同。
MySQL的恢復和復制對InnoDB鎖機制和一致性讀策略也有較大影響。
鎖沖突甚至死鎖很難完全避免。
在了解InnoDB鎖特性后，用戶可以通過設計和SQL調整等措施減少鎖沖突和死鎖，包括：
盡量使用較低的隔離級別；
精心設計索引，並盡量使用索引訪問數據，使加鎖更精確，從而減少鎖沖突的機會；
選擇合理的事務大小，小事務發生鎖沖突的幾率也更小；
給記錄集顯示加鎖時，最好一次性請求足夠級別的鎖。比如要修改數據的話，最好直接申請排他鎖，而不是先申請共享鎖，修改時再請求排他鎖，這樣容易產生死鎖；
不同的程序訪問一組表時，應盡量約定以相同的順序訪問各表，對一個表而言，盡可能以固定的順序存取表中的行。這樣可以大大減少死鎖的機會；
盡量用相等條件訪問數據，這樣可以避免間隙鎖對並發插入的影響；
不要申請超過實際需要的鎖級別；除非必須，查詢時不要顯示加鎖；
對於一些特定的事務，可以使用表鎖來提高處理速度或減少死鎖的可能。
什么情況下使用表鎖
表級鎖在下列幾種情況下比行級鎖更優越：
- 很多操作都是讀表。
- 在嚴格條件的索引上讀取和更新，當更新或者刪除可以用單獨的索引來讀取得到時：
- UPDATE tbl_name SET column=value WHERE unique_key_col=key_value;
- DELETE FROM tbl_name WHERE unique_key_col=key_value;
- SELECT 和 INSERT 語句並發的執行，但是只有很少的 UPDATE 和 DELETE 語句。
- 很多的掃描表和對全表的 GROUP BY 操作，但是沒有任何寫表。
什么情況下使用行鎖
行級鎖定的優點：
- 當在許多線程中訪問不同的行時只存在少量鎖定沖突。
- 回滾時只有少量的更改。
- 可以長時間鎖定單一的行。
行級鎖定的缺點：
- 比頁級或表級鎖定占用更多的內存。
- 當在表的大部分中使用時，比頁級或表級鎖定速度慢，因為你必須獲取更多的鎖。
- 如果你在大部分數據上經常進行GROUP BY操作或者必須經常掃描整個表，比其它鎖定明顯慢很多。
- 用高級別鎖定，通過支持不同的類型鎖定，你也可以很容易地調節應用程序，因為其鎖成本小於行級鎖定。
如何減少鎖沖突
對Myisam類型的表：
1）Myisam類型的表可以考慮通過改成Innodb類型的表來減少鎖沖突。
2）根據應用的情況，嘗試橫向拆分成多個表或者改成Myisam分區對減少鎖沖突也會有一定的幫助。
對InnoDB類型的表：
1） 首先要確認，在對表獲取行鎖的時候，要盡量的使用索引檢索記錄，如果沒有使用索引訪問，那么即便你只是要更新其中的一行紀錄，也是全表鎖定的。要確保sql是使用索引來訪問記錄的，必要的時候，請使用explain檢查sql的執行計划，判斷是否按照預期使用了索引。
2) 由於mysql的行鎖是針對索引加的鎖，不是針對記錄加的鎖，所以雖然是訪問不同行的記錄，但是如果是相同的索引鍵，是會被加鎖的。應用設計的時候也要注意，這里和Oracle有比較大的不同。
3) 當表有多個索引的時候，不同的事務可以使用不同的索引鎖定不同的行，當表有主鍵或者唯一索引的時候，不是必須使用主鍵或者唯一索引鎖定記錄，其他普通索引同樣可以用來檢索記錄，並只鎖定符合條件的行。
4) 用SHOW INNODB STATUS來確定最后一個死鎖的原因。查詢的結果中，包括死鎖的事務的詳細信息，包括執行的SQL語句的內容，每個線程已經獲得了什么鎖，在等待什么鎖，以及最后是哪個線程被回滾。詳細的分析死鎖產生的原因，可以通過改進程序有效的避免死鎖的產生。
5) 如果應用並不介意死鎖的出現，那么可以在應用中對發現的死鎖進行處理。
6) 確定更合理的事務大小，小事務更少地傾向於沖突。
7) 如果你正使用鎖定讀，（SELECT ... FOR UPDATE或 ... LOCK IN SHARE MODE），試着用更低的隔離級別，比如READ COMMITTED。
8) 以固定的順序訪問你的表和行。則事務形成良好定義的查詢並且沒有死鎖。
引用：
http://muxucao.cn/news-165.html