前言

最近老顧經常碰到同事說，MySQL又死鎖了導致業務報錯。今天我們就來聊聊死鎖以及怎么解決

鎖類型

mysql鎖級別：頁級、表級、行級

表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖沖突的概率最高,并發度最低。

行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖沖突的概率最低,并發度也最高。

頁面鎖：開銷和加鎖時間界于表鎖和行鎖之間；會出現死鎖；鎖定粒度界于表鎖和行鎖之間，并發度一般

死鎖產生原因和示例

1、產生原因：

死鎖是指兩個或兩個以上的進程在執行過程中,因爭奪資源而造成的一種互相等待的現象,若無外力作用，它們都將無法推進下去.此時稱系統處于死鎖狀態或系統產生了死鎖，這些永遠在互相等待的進程稱為死鎖進程。表級鎖不會產生死鎖.所以解決死鎖主要還是針對于最常用的InnoDB。

死鎖的關鍵在于：兩個(或以上)的Session加鎖的順序不一致。

那么對應的解決死鎖問題的關鍵就是：讓不同的session加鎖有次序

2、產生示例：

案例一

需求：將投資的錢拆成幾份隨機分配給借款人。

起初業務程序思路是這樣的：

投資人投資后，將金額隨機分為幾份，然后隨機從借款人表里面選幾個，然后通過一條條select for update 去更新借款人表里面的余額等。

例如兩個用戶同時投資，A用戶金額隨機分為2份，分給借款人1，2

B用戶金額隨機分為2份，分給借款人2，1

由于加鎖的順序不一樣，死鎖當然很快就出現了。

對于這個問題的改進很簡單，直接把所有分配到的借款人直接一次鎖住就行了。

Select * from xxx where id in (xx,xx,xx) for update

在in里面的列表值mysql是會自動從小到大排序，加鎖也是一條條從小到大加的鎖

第一個會話：

注意：關閉掉自動提交set autocommit=0;

mysql> select * from goods where goods_id in (2,3) for update;
+----+--------+------+---------------------+
| good_id | goods_name | price             |
+----+--------+------+---------------------+
|  2 | bbbb     | 1.00 |
|  3 | vvv     | 3.00 |
+----+--------+------+---------------------+

第二個會話:

select * from goods where goods_id in (3,4,5) for update;

鎖等待中……

案例二

在開發中，經常會做這類的判斷需求：根據字段值查詢（有索引），如果不存在，則插入；否則更新。

以id為主鍵為例，目前還沒有id=22的行

注意：關閉掉自動提交set autocommit=0;

第一個會話:

select * from goods where goods_id=22 for update;

第二個會話:

select * from goods where goods_id=23  for update;

再在第一個會話:

insert into goods values(22,'ac',11.5);

鎖等待中……

再到第二個會話:

insert into goods values(23,'bc',23.0);

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

當對存在的行進行鎖的時候(主鍵)，mysql就只有行鎖。

當對未存在的行進行鎖的時候(即使條件為主鍵)，mysql是會鎖住一段范圍

鎖住的范圍為：

(無窮小或小于表中鎖住id的最大值，無窮大或大于表中鎖住id的最小值)

如一：如果表中目前有已有的id為（11 ， 12）

那么就鎖住（12，無窮大）

如二：如果表中目前已有的id為（11 ， 30）

那么就鎖住（11，30）

對于這種死鎖的解決辦法是：

insert into goods(xx,xx) on duplicate key update `xx`='XX';

用mysql特有的語法來解決此問題。因為insert語句對于主鍵來說，插入的行不管有沒有存在，都會只有行鎖

死鎖檢查處理

正常情況下，死鎖發生時，權重最小的連接將被kill并回滾。但是為了找出語句來優化，啟用可啟用死鎖將死鎖信息記錄下來。

#step 1：窗口一
mysql> start transaction;
mysql> update aa set name='aaa' where id = 1;
 
#step 2：窗口二
mysql> start transaction;
mysql> update bb set name='bbb' where id = 1;
 
#step 3：窗口一
mysql> update bb set name='bbb';

查看方式

#step 4：窗口三
#是否自動提交
mysql> show variables like 'autocommit';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit    | ON    |
+---------------+-------+
 

查看當前鏈接

#查看當前連接
mysql> show processlist;
mysql> show full processlist;
mysql> SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST;
+----+------+-----------+------+---------+------+-------+------------------+
| Id | User | Host      | db   | Command | Time | State | Info             |
+----+------+-----------+------+---------+------+-------+------------------+
|  4 | root | localhost | test | Sleep   |  244 |       | NULL             |
|  5 | root | localhost | test | Sleep   |  111 |       | NULL             |
|  6 | root | localhost | NULL | Query   |    0 | init  | show processlist |
+----+------+-----------+------+---------+------+-------+------------------+
 

• id列:一個標識，你要kill 一個語句的時候很有用。
• user列: 顯示當前用戶，如果不是root，這個命令就只顯示你權限范圍內的sql語句。
• host列:顯示這個語句是從哪個ip 的哪個端口上發出的。可用來追蹤出問題語句的用戶。
• db列:顯示這個進程目前連接的是哪個數據庫。
• command列:顯示當前連接的執行的命令，一般就是休眠（sleep），查詢（query），連接（connect）
• time列:此這個狀態持續的時間，單位是秒。

這個命令中最關鍵的就是state列，mysql列出的狀態主要有以下幾種：

Checking table

正在檢查數據表（這是自動的）。

Closing tables

正在將表中修改的數據刷新到磁盤中，同時正在關閉已經用完的表。這是一個很快的操作，如果不是這樣的話，就應該確認磁盤空間是否已經滿了或者磁盤是否正處于重負中。

Connect Out

復制從服務器正在連接主服務器。

Copying to tmp table on disk

由于臨時結果集大于tmp_table_size，正在將臨時表從內存存儲轉為磁盤存儲以此節省內存。

Creating tmp table

正在創建臨時表以存放部分查詢結果。

deleting from main table

服務器正在執行多表刪除中的第一部分，剛刪除第一個表。

deleting from reference tables

服務器正在執行多表刪除中的第二部分，正在刪除其他表的記錄。

Flushing tables

正在執行FLUSH TABLES，等待其他線程關閉數據表。

Killed

發送了一個kill請求給某線程，那么這個線程將會檢查kill標志位，同時會放棄下一個kill請求。MySQL會在每次的主循環中檢查kill標志位，不過有些情況下該線程可能會過一小段才能死掉。如果該線程程被其他線程鎖住了，那么kill請求會在鎖釋放時馬上生效。

Locked

被其他查詢鎖住了。

Sending data

正在處理SELECT查詢的記錄，同時正在把結果發送給客戶端。

Sorting for group

正在為GROUP BY做排序。

Sorting for order

正在為ORDER BY做排序。

Opening tables

這個過程應該會很快，除非受到其他因素的干擾。例如，在執ALTER TABLE或LOCK TABLE語句行完以前，數據表無法被其他線程打開。正嘗試打開一個表。

Removing duplicates

正在執行一個SELECT DISTINCT方式的查詢，但是MySQL無法在前一個階段優化掉那些重復的記錄。因此，MySQL需要再次去掉重復的記錄，然后再把結果發送給客戶端。

Reopen table

獲得了對一個表的鎖，但是必須在表結構修改之后才能獲得這個鎖。已經釋放鎖，關閉數據表，正嘗試重新打開數據表。

Repair by sorting

修復指令正在排序以創建索引。

Repair with keycache

修復指令正在利用索引緩存一個一個地創建新索引。它會比Repair by sorting慢些。

Searching rows for update

正在講符合條件的記錄找出來以備更新。它必須在UPDATE要修改相關的記錄之前就完成了。

Sleeping

正在等待客戶端發送新請求.

System lock

正在等待取得一個外部的系統鎖。如果當前沒有運行多個mysqld服務器同時請求同一個表，那么可以通過增加--skip-external-locking參數來禁止外部系統鎖。

Upgrading lock

INSERT DELAYED正在嘗試取得一個鎖表以插入新記錄。

Updating

正在搜索匹配的記錄，并且修改它們。

User Lock

正在等待GET_LOCK()。

Waiting for tables

該線程得到通知，數據表結構已經被修改了，需要重新打開數據表以取得新的結構。然后，為了能的重新打開數據表，必須等到所有其他線程關閉這個表。以下幾種情況下會產生這個通知：FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE,或OPTIMIZE TABLE。

Waiting for handler insert

INSERT DELAYED已經處理完了所有待處理的插入操作，正在等待新的請求。

查看當前正在被鎖的事務

 
#查看當前正在被鎖的事務（鎖請求超時后則查不到）
mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;
+------------------+-------------+-----------+-----------+-------------+-----------------+------------+-----------+----------+----------------+
| lock_id          | lock_trx_id | lock_mode | lock_type | lock_table  | lock_index      | lock_space | lock_page | lock_rec | lock_data      |
+------------------+-------------+-----------+-----------+-------------+-----------------+------------+-----------+----------+----------------+
| 130718495:65:3:4 | 130718495   | X         | RECORD    | `test`.`bb` | GEN_CLUST_INDEX |         65 |         3 |        4 | 0x000000000300 |
| 130718496:65:3:4 | 130718496   | X         | RECORD    | `test`.`bb` | GEN_CLUST_INDEX |         65 |         3 |        4 | 0x000000000300 |
+------------------+-------------+-----------+-----------+-------------+-----------------+------------+-----------+----------+----------------+
 

查看當前等待鎖的事務

#查看當前等待鎖的事務（鎖請求超時后則查不到）
mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS; 
+-------------------+-------------------+-----------------+------------------+
| requesting_trx_id | requested_lock_id | blocking_trx_id | blocking_lock_id |
+-------------------+-------------------+-----------------+------------------+
| 130718499         | 130718499:65:3:4  | 130718500       | 130718500:65:3:4 |
+-------------------+-------------------+-----------------+------------------+
 

查看當前未提交的事務

 
#查看當前未提交的事務（如果死鎖等待超時,事務可能還沒有關閉）
mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;

 

主要看箭頭指向的這幾個字段，如果有阻塞數據（不為0的就是阻塞的）,找到后在根據下圖這個字段：try_mysql_thread_id 作為這條數據的主鍵id執行這個sql進行刪除： kill id ;(殺死對應id的進程).假設這里try_mysql_thread_id=14的這條數據是鎖了。我們執行 kill 14刪除就不再鎖表了。

查看正在被訪問的表

#查看正在被訪問的表
mysql> show OPEN TABLES where In_use > 0;
+----------+-------+--------+-------------+
| Database | Table | In_use | Name_locked |
+----------+-------+--------+-------------+
| test     | bb    |      1 |           0 |
+----------+-------+--------+-------------+

死鎖異常

#step 3：窗口一 （若第三步中鎖請求太久，則出現鎖超時而終止執行）
mysql> update bb set name='bbb';
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
 
 
#"窗口一" 鎖請求超時前，執行第五步，使死鎖產生，則該連接 "窗口二" 執行終止，"窗口一" 順利執行
#step 5：窗口二
mysql> update aa set name='aa';
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

查看最近一個死鎖情況

mysql> SHOW ENGINE INNODB STATUS;

 

相關參數配置

死鎖日志

#死鎖記錄只記錄最近一個死鎖信息，若要將每個死鎖信息都保存到錯誤日志，啟用以下參數：
mysql> show variables like 'innodb_print_all_deadlocks';
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| innodb_print_all_deadlocks | OFF   |
+----------------------------+-------+
 

鎖等待超時

 
#上面 【step 3：窗口一】若一直請求不到資源，默認50秒則出現鎖等待超時。
mysql> show variables like 'innodb_lock_wait_timeout'; 
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| innodb_lock_wait_timeout | 50    |
+--------------------------+-------+
 
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
 
 
#設置全局變量 鎖等待超時為60秒（新的連接生效）
#mysql> set session innodb_lock_wait_timeout=50; 
mysql> set global innodb_lock_wait_timeout=60; 
 

事務回滾

 
#上面測試中，當事務中的某個語句超時只回滾該語句，事務的完整性屬于被破壞了。為了回滾這個事務，啟用以下參數：
mysql> show variables like 'innodb_rollback_on_timeout';
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| innodb_rollback_on_timeout | OFF   |
+----------------------------+-------+

最終參數設置如下：(重啟服務重新連接測試)

[mysqld]
log-error =/var/log/mysqld3306.log
innodb_lock_wait_timeout=60     #鎖請求超時時間(秒)
innodb_rollback_on_timeout = 1  #事務中某個語句鎖請求超時將回滾真個事務
innodb_print_all_deadlocks = 1  #死鎖都保存到錯誤日志

Command='Sleep'

表示連接休眠，如果太多，可以手動刪除

#若手動刪除堵塞會話，刪除 Command='Sleep' 、無State、無Info、trx_weight 權重最小的。
show processlist;
SELECT trx_mysql_thread_id,trx_state,trx_started,trx_weight FROM INFORMATION_SCHEMA.INNODB_TRX;

總結

上面是老顧總結的mysql死鎖相關的內容，尤其是死鎖檢查處理，是比較實用的，小伙伴們可以參考。

---

推薦閱讀

解決Api統一格式返回，遺留地返回String一個問題

SpringMVC全局異常方案、源碼分析，以及常見的入坑

Spring多種啟動初始化方案，看這篇就夠了

來說說ThreadLocal內存溢出問題

阿里面試題：強、軟、弱、虛引用的特點及應用場景

企業常用的并發編程Queue的源碼分析

了解JAVA中的SPI機制，以及數據庫驅動插件，這一篇就夠了

企業實戰之阿里druid統一監控方案，你了解嗎？

千人千面精準推薦之大白話講解協同算法（一）,看這篇就夠了

企業實戰之分布式鎖方案一步步的演變

你了解滑動時間窗口嗎？Sentinel核心源碼剖析

Sentinel全局Feign默認熔斷降級策略的思考

你所不知道的頭部參數傳遞的坑，來吧！抓緊出坑

5分鐘讓你理解K8S必備架構概念，以及網絡模型（一）

5分鐘讓你理解K8S必備架構概念，以及網絡模型（二）

5分鐘讓你理解K8S必備架構概念，以及網絡模型（三）

大廠如何基于binlog解決多機房同步mysql數據（一）？

大廠如何基于binlog解決多機房同步mysql數據（二）？

基于binlog的canal組件有哪些使用場景（三）？

基于binlog日志之canal企業應用及高可用原理（四）？

可用于大型應用的微服務生態灰度發布如何實現？

一線大廠級別公共redis集群監控，細化到每個項目實例

Sharding-jdbc的實戰入門之水平分表（一）

Sharding-Jdbc之水平分庫和讀寫分離（二）