mysql 死鎖原因及解決辦法

Mysql 鎖類型

一、鎖類型介紹：

MySQL 有三種鎖的級別：頁級、表級、行級。

• 表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖衝突的概率最高，併發度最低。
• 行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖衝突的概率最低，併發度也最高。
• 頁面鎖：開銷和加鎖時間界於表鎖和行鎖之間；會出現死鎖；鎖定粒度界於表鎖和行鎖之間，併發度一般

算法：

• next KeyLocks 鎖，同時鎖住記錄 (數據)，並且鎖住記錄前面的 Gap
• Gap 鎖，不鎖記錄，僅僅記錄前面的 Gap
• Recordlock 鎖（鎖數據，不鎖 Gap）
• 所以其實 Next-KeyLocks=Gap 鎖 + Recordlock 鎖

二、死鎖產生原因和示例

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 是會自動從小到大排序，加鎖也是一條條從小到大加的鎖

例如（以下會話 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 |
+----+--------+------+---------------------+
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 |
+----+--------+------+---------------------+
row in set (0.00 sec)

在其它 session 中 id=5 是加不了鎖的，但是 id=10 是可以加上鎖的。

案例二

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

以 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 語句對於主鍵來說，插入的行不管有沒有存在，都會只有行鎖

搜索 Java 知音公衆號，回覆 “後端面試”，送你一份 Java 面試題寶典.pdf

案例三

mysql> select * from t3 where id=9 for update;
+----+--------+------+---------------------+
| id | course | name | ctime               |
+----+--------+------+---------------------+
|  9 | JX     | f    | 2016-03-01 11:36:30 |
+----+--------+------+---------------------+
 
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 的行，這就有點跳了，當然肯定也有解決的方法，那就是重理業務需求，避免這樣的寫法。

案例四

案例四

一般的情況，兩個 session 分別通過一個 sql 持有一把鎖，然後互相訪問對方加鎖的數據產生死鎖。

案例五

案例五

兩個單條的 sql 語句涉及到的加鎖數據相同，但是加鎖順序不同，導致了死鎖。

案例六

死鎖場景如下：

表結構：

CREATE TABLE dltask (
    id bigint unsigned NOT NULL AUTO_INCREMENT COMMENT ‘auto id’,
    a varchar(30) NOT NULL COMMENT ‘uniq.a’,
    b varchar(30) NOT NULL COMMENT ‘uniq.b’,
    c varchar(30) NOT NULL COMMENT ‘uniq.c’,
    x varchar(30) NOT NULL COMMENT ‘data’,   
    PRIMARY KEY (id),
    UNIQUE KEY uniq_a_b_c (a, b, c)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT=’deadlock test’;

a，b，c 三列，組合成一個唯一索引，主鍵索引爲 id 列。

事務隔離級別：

RR (Repeatable Read)

每個事務只有一條 SQL：

delete from dltask where a=? and b=? and c=?;

SQL 的執行計劃：

執行計劃

死鎖日誌：

死鎖日誌

衆所周知，InnoDB 上刪除一條記錄，並不是真正意義上的物理刪除，而是將記錄標識爲刪除狀態。(注：這些標識爲刪除狀態的記錄，後續會由後臺的 Purge 操作進行回收，物理刪除。但是，刪除狀態的記錄會在索引中存放一段時間。) 在 RR 隔離級別下，唯一索引上滿足查詢條件，但是卻是刪除記錄，如何加鎖？InnoDB 在此處的處理策略與前兩種策略均不相同，或者說是前兩種策略的組合：對於滿足條件的刪除記錄，InnoDB 會在記錄上加 next key lock X (對記錄本身加 X 鎖，同時鎖住記錄前的 GAP，防止新的滿足條件的記錄插入。) Unique 查詢，三種情況，對應三種加鎖策略，總結如下：

此處，我們看到了 next key 鎖，是否很眼熟？對了，前面死鎖中事務 1，事務 2 處於等待狀態的鎖，均爲 next key 鎖。明白了這三個加鎖策略，其實構造一定的併發場景，死鎖的原因已經呼之欲出。但是，還有一個前提策略需要介紹，那就是 InnoDB 內部採用的死鎖預防策略。

• 找到滿足條件的記錄，並且記錄有效，則對記錄加 X 鎖，No Gap 鎖 (lock_mode X locks rec but not gap)；
• 找到滿足條件的記錄，但是記錄無效 (標識爲刪除的記錄)，則對記錄加 next key 鎖 (同時鎖住記錄本身，以及記錄之前的 Gap：lock_mode X);
• 未找到滿足條件的記錄，則對第一個不滿足條件的記錄加 Gap 鎖，保證沒有滿足條件的記錄插入 (locks gap before rec)；

死鎖預防策略

InnoDB 引擎內部 (或者說是所有的數據庫內部)，有多種鎖類型：事務鎖 (行鎖、表鎖)，Mutex (保護內部的共享變量操作)、RWLock (又稱之爲 Latch，保護內部的頁面讀取與修改)。

InnoDB 每個頁面爲 16K，讀取一個頁面時，需要對頁面加 S 鎖，更新一個頁面時，需要對頁面加上 X 鎖。任何情況下，操作一個頁面，都會對頁面加鎖，頁面鎖加上之後，頁面內存儲的索引記錄纔不會被併發修改。

因此，爲了修改一條記錄，InnoDB 內部如何處理：

• 根據給定的查詢條件，找到對應的記錄所在頁面；
• 對頁面加上 X 鎖 (RWLock)，然後在頁面內尋找滿足條件的記錄；
• 在持有頁面鎖的情況下，對滿足條件的記錄加事務鎖 (行鎖：根據記錄是否滿足查詢條件，記錄是否已經被刪除，分別對應於上面提到的 3 種加鎖策略之一)；

相對於事務鎖，頁面鎖是一個短期持有的鎖，而事務鎖 (行鎖、表鎖) 是長期持有的鎖。因此，爲了防止頁面鎖與事務鎖之間產生死鎖。InnoDB 做了死鎖預防的策略：持有事務鎖 (行鎖、表鎖)，可以等待獲取頁面鎖；但反之，持有頁面鎖，不能等待持有事務鎖。

根據死鎖預防策略，在持有頁面鎖，加行鎖的時候，如果行鎖需要等待。則釋放頁面鎖，然後等待行鎖。此時，行鎖獲取沒有任何鎖保護，因此加上行鎖之後，記錄可能已經被併發修改。因此，此時要重新加回頁面鎖，重新判斷記錄的狀態，重新在頁面鎖的保護下，對記錄加鎖。如果此時記錄未被併發修改，那麼第二次加鎖能夠很快完成，因爲已經持有了相同模式的鎖。但是，如果記錄已經被併發修改，那麼，就有可能導致本文前面提到的死鎖問題。

以上的 InnoDB 死鎖預防處理邏輯，對應的函數，是 row0sel.c::row_search_for_mysql ()。感興趣的朋友，可以跟蹤調試下這個函數的處理流程，很複雜，但是集中了 InnoDB 的精髓。搜索 Java 知音公衆號，回覆 “後端面試”，送你一份 Java 面試題寶典.pdf

剖析死鎖的成因

做了這麼多鋪墊，有了 Delete 操作的 3 種加鎖邏輯、InnoDB 的死鎖預防策略等準備知識之後，再回過頭來分析本文最初提到的死鎖問題，就會手到拈來，事半而功倍。

首先，假設 dltask 中只有一條記錄：(1, ‘a’, ‘b’, ‘c’, ‘data’)。三個併發事務，同時執行以下的這條 SQL：

delete from dltask where a=’a’ and b=’b’ and c=’c’;

並且產生了以下的併發執行邏輯，就會產生死鎖：

併發執行邏輯

上面分析的這個併發流程，完整展現了死鎖日誌中的死鎖產生的原因。其實，根據事務 1 步驟 6，與事務 0 步驟 3/4 之間的順序不同，死鎖日誌中還有可能產生另外一種情況，那就是事務 1 等待的鎖模式爲記錄上的 X 鎖 + No Gap 鎖 (lock_mode X locks rec but not gap waiting)。這第二種情況，也是” 潤潔” 同學給出的死鎖用例中，使用 MySQL 5.6.15 版本測試出來的死鎖產生的原因。

此類死鎖，產生的幾個前提：

• Delete 操作，針對的是唯一索引上的等值查詢的刪除；(範圍下的刪除，也會產生死鎖，但是死鎖的場景，跟本文分析的場景，有所不同)
• 至少有 3 個 (或以上) 的併發刪除操作；
• 併發刪除操作，有可能刪除到同一條記錄，並且保證刪除的記錄一定存在；
• 事務的隔離級別設置爲 Repeatable Read，同時未設置 innodb_locks_unsafe_for_binlog 參數 (此參數默認爲 FALSE)；(Read Committed 隔離級別，由於不會加 Gap 鎖，不會有 next key，因此也不會產生死鎖)
• 使用的是 InnoDB 存儲引擎；(廢話！MyISAM 引擎根本就沒有行鎖)

 

如何檢測代碼運行是否出現死鎖

解除正在死鎖的狀態有兩種方法：

第一種：

1.查詢是否鎖表

show OPEN TABLES where In_use > 0;

2.查詢進程（如果您有SUPER權限，您可以看到所有線程。否則，您只能看到您自己的線程）

show processlist

3.殺死進程id（就是上面命令的id列）

kill id

 

第二種：

1.查看下在鎖的事務

SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;

2.殺死進程id（就是上面命令的trx_mysql_thread_id列）

kill 線程ID

例子：

查出死鎖進程：SHOW PROCESSLIST
殺掉進程          KILL 420821;

其它查看死鎖的命令：

1：查看當前的事務
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;

2：查看當前鎖定的事務

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;

3：查看當前等鎖的事務
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;

 

MySQL 死鎖檢查處理

正常情況下，死鎖發生時，權重最小的連接將被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 |
+----+------+-----------+------+---------+------+-------+------------------+
 
 
#查看當前正在被鎖的事務（鎖請求超時後則查不到）
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;
+--------------------------------------------------------------------------------------------------------+
| trx_id    | trx_state | trx_started         | trx_requested_lock_id | trx_wait_started    | trx_weight |
+-----------+-----------+---------------------+-----------------------+---------------------+------------+
| 130718500 | RUNNING   | 2018-03-12 09:28:10 | NULL                  | NULL                |          3 |
| 130718499 | LOCK WAIT | 2018-03-12 09:27:59 | 130718499:65:3:4      | 2018-03-12 09:32:48 |          5 |
==========================================================================================================
| trx_mysql_thread_id | trx_query                             | trx_operation_state | trx_tables_in_use |
+---------------------+---------------------------------------+---------------------+-------------------+
|                   4 | NULL                                  | NULL                |                 0 |
|                   5 | update bb set name='bbb'              | starting index read |                 1 |
=========================================================================================================
| trx_tables_locked | trx_lock_structs | trx_lock_memory_bytes | trx_rows_locked | trx_rows_modified |
+-------------------+------------------+-----------------------+-----------------+-------------------+
|                 0 |                2 |                   360 |               3 |                 1 |
|                 1 |                4 |                  1184 |               4 |                 1 |
===========================================================================================================================
| trx_concurrency_tickets | trx_isolation_level | trx_unique_checks | trx_foreign_key_checks | trx_last_foreign_key_error |
+-------------------------+---------------------+-------------------+------------------------+----------------------------+
|                       0 | REPEATABLE READ     |                 1 |                      1 | NULL                       |
|                       0 | REPEATABLE READ     |                 1 |                      1 | NULL                       |
===========================================================================================================================
| trx_adaptive_hash_latched | trx_adaptive_hash_timeout | trx_is_read_only | trx_autocommit_non_locking |
+---------------------------+---------------------------+------------------+----------------------------+
|                         0 |                     10000 |                0 |                          0 |
|                         0 |                     10000 |                0 |                          0 |
+---------------------------+---------------------------+------------------+----------------------------+
 
 
#查看正在被訪問的表
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\G ;
...............
------------------------
LATEST DETECTED DEADLOCK
------------------------
2018-03-12 11:01:06 7ffb4993a700 #發生時間
*** (1) TRANSACTION: #事務1
TRANSACTION 130718515, ACTIVE 19 sec starting index read
mysql tables in use 1, locked 1 #正被訪問的表
LOCK WAIT 4 lock struct(s), heap size 1184, 4 row lock(s), undo log entries 1 #影響行數
MySQL thread id 5, OS thread handle 0x7ffb498f8700, query id 205 localhost root updating #線程/連接host/用戶
update bb set name='bb' #請求語句
*** (1) WAITING FOR THIS LOCK TO BE GRANTED: #等待以下資源 （鎖定位置及鎖模式）
RECORD LOCKS space id 65 page no 3 n bits 72 index `GEN_CLUST_INDEX` of table `test`.`bb` trx id 130718515 lock_mode X waiting
Record lock, heap no 5 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 6; hex 000000000300; asc       ;;
 1: len 6; hex 000007ca9b34; asc      4;;
 2: len 7; hex 1f000002092075; asc       u;;
 3: len 4; hex 80000001; asc     ;;
 4: len 2; hex 6262; asc bb;;
 
*** (2) TRANSACTION: #事務2
TRANSACTION 130718516, ACTIVE 14 sec starting index read
mysql tables in use 1, locked 1
4 lock struct(s), heap size 1184, 4 row lock(s), undo log entries 1
MySQL thread id 4, OS thread handle 0x7ffb4993a700, query id 206 localhost root updating
update aa set name='aa' #請求語句
*** (2) HOLDS THE LOCK(S): #持有鎖資源
RECORD LOCKS space id 65 page no 3 n bits 72 index `GEN_CLUST_INDEX` of table `test`.`bb` trx id 130718516 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;
 
Record lock, heap no 3 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 6; hex 000000000301; asc       ;;
 1: len 6; hex 000007ca9b17; asc       ;;
 2: len 7; hex 9000000144011e; asc     D  ;;
 3: len 4; hex 80000002; asc     ;;
 4: len 2; hex 6262; asc bb;;
 
Record lock, heap no 5 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 6; hex 000000000300; asc       ;;
 1: len 6; hex 000007ca9b34; asc      4;;
 2: len 7; hex 1f000002092075; asc       u;;
 3: len 4; hex 80000001; asc     ;;
 4: len 2; hex 6262; asc bb;;
 
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 64 page no 3 n bits 80 index `GEN_CLUST_INDEX` of table `test`.`aa` trx id 130718516 lock_mode X waiting
Record lock, heap no 7 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 6; hex 000000000200; asc       ;;
 1: len 6; hex 000007ca9b33; asc      3;;
 2: len 7; hex 1e000001d53057; asc      0W;;
 3: len 4; hex 80000001; asc     ;;
 4: len 2; hex 6161; asc aa;;
 
*** WE ROLL BACK TRANSACTION (2)
...............
#死鎖記錄只記錄最近一個死鎖信息，若要將每個死鎖信息都保存到錯誤日誌，啓用以下參數：
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' 、無State、無Info、trx_weight 權重最小的。
show processlist;
SELECT trx_mysql_thread_id,trx_state,trx_started,trx_weight FROM INFORMATION_SCHEMA.INNODB_TRX;