記一次神奇的Mysql死鎖排查

背景

提及Mysql死鎖，以前寫過一次有關Mysql加鎖的基本介紹，對於一些基本的Mysql鎖或者死鎖都有一個簡單的認識，能夠看下這篇文章爲何開發人員須要瞭解數據庫鎖。有了上面的經驗以後，本覺得對於死鎖都能手到擒來，沒想到再一個陽光明媚的下午報出了一個死鎖，可是這一次卻沒想象的那麼簡單。

問題初現

在某天下午，忽然系統報警，拋出個異常:

仔細一看好像是事務回滾異常，寫着的是由於死鎖回滾，原來是個死鎖問題，因爲我對Mysql鎖仍是有必定 瞭解的，因而開始主動排查這個問題。

首先在數據庫中查找Innodb Status，在Innodb Status中會記錄上一次死鎖的信息,輸入下面命令:

SHOW ENGINE INNODB STATUS

死鎖信息以下,sql信息進行了簡單處理:

------------------------
LATEST DETECTED DEADLOCK
------------------------
2019-02-22 15:10:56 0x7eec2f468700
*** (1) TRANSACTION:
TRANSACTION 2660206487, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 31261312, OS thread handle 139554322093824, query id 11624975750 10.23.134.92 erp_crm__6f73 updating
/*id:3637ba36*/UPDATE tenant_config SET
       open_card_point =  0
       where tenant_id = 123
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1322 page no 534 n bits 960 index uidx_tenant of table `erp_crm_member_plan`.`tenant_config` trx id 2660206487 lock_mode X locks rec but not gap waiting

*** (2) TRANSACTION:
TRANSACTION 2660206486, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 31261311, OS thread handle 139552870532864, query id 11624975758 10.23.134.92 erp_crm__6f73 updating
/*id:3637ba36*/UPDATE tenant_config SET
       open_card_point =  0
       where tenant_id = 123
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 1322 page no 534 n bits 960 index uidx_tenant of table `erp_crm_member_plan`.`tenant_config` trx id 2660206486 lock mode S
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1322 page no 534 n bits 960 index uidx_tenant of table `erp_crm_member_plan`.`tenant_config` trx id 2660206486 lock_mode X locks rec but not gap waiting
*** WE ROLL BACK TRANSACTION (1)
------------

給你們簡單的分析解釋一下這段死鎖日誌，事務1執行Update語句的時候須要獲取uidx_tenant這個索引再where條件上的X鎖(行鎖)，事務2執行一樣的Update語句，也在uidx_tenant上面想要獲取X鎖(行鎖)，而後就出現了死鎖，回滾了事務1。當時我就很懵逼，回想了一下死鎖產生的必要條件:

1. 互斥。
2. 請求與保持條件。
3. 不剝奪條件。
4. 循環等待。 從日誌上來看事務1和事務2都是取爭奪同一行的行鎖，和以往的互相循環爭奪鎖有點不一樣，怎麼看都沒法知足循環等待條件。通過同事提醒，既然從死鎖日誌中不能進行排查，那麼就只能從業務代碼和業務日誌從排查。這段代碼的邏輯以下:

public int saveTenantConfig(PoiContext poiContext, TenantConfigDO tenantConfig) {
        try {
            return tenantConfigMapper.saveTenantConfig(poiContext.getTenantId(), poiContext.getPoiId(), tenantConfig);
        } catch (DuplicateKeyException e) {
            LOGGER.warn("[saveTenantConfig] 主鍵衝突，更新該記錄。context:{}, config:{}", poiContext, tenantConfig);
            return tenantConfigMapper.updateTenantConfig(poiContext.getTenantId(), tenantConfig);
        }
    }

這段代碼的意思是保存一個配置文件，若是發生了惟一索引衝突那麼就會進行更新，固然這裏可能寫得不是很規範，其實能夠用

insert into ... 
on duplicate key update

也能夠達到一樣的效果，可是就算用這個其實也會發生死鎖。看了代碼以後同事又給我發了當時業務日誌,

能夠看見這裏有三條同時發生的日誌，說明都發生了惟一索引衝突進入了更新的語句，而後發生的死鎖。到這裏答案終於稍微有點眉目了。

這個時候再看咱們的表結構以下(作了簡化處理):

CREATE TABLE `tenant_config` (
  `id` bigint(21) NOT NULL AUTO_INCREMENT,
  `tenant_id` int(11) NOT NULL,
  `open_card_point` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uidx_tenant` (`tenant_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8mb4 ROW_FORMAT=COMPACT

咱們的tenant_id是用來作惟一索引，咱們的插入和更新的where條件都是基於惟一索引來操做的。

UPDATE tenant_config SET
       open_card_point =  0
       where tenant_id = 123

到了這裏感受插入的時候對惟一索引加鎖有關係，接下來咱們進行下一步的深刻剖析。

深刻剖析

上面咱們說有三個事務進入update語句，爲了簡化說明這裏咱們只須要兩個事務同時進入update語句便可，下面的表格展現了咱們整個的發生過程:

時間線	事務1	事務2	事務3
1	insert into xx	insert into xx	insert into xx
2	獲取當前行X鎖
3		須要檢測惟一索引是否衝突獲取S鎖，阻塞	須要檢測惟一索引是否衝突獲取S鎖，阻塞
4	commit;	獲取到到S鎖	獲取到S鎖
5		發現惟一索引衝突，執行Update語句(此時S鎖未釋放)	發現惟一索引衝突，執行Update語句
6		獲取該行的X鎖，被事務3的S鎖阻塞	獲取該行的X鎖，被事務2的S鎖阻塞
7		發現死鎖，回滾該事務	update成功,commit;

小提示:S鎖是共享鎖，X鎖是互斥鎖。通常來講X鎖和S，X鎖都互斥，S鎖和S鎖不互斥。

咱們從上面的流程中看見發生這個死鎖的關鍵須要獲取S鎖，爲何咱們再插入的時候須要獲取S鎖呢？由於咱們須要檢測惟一索引？在RR隔離級別下若是要讀取那麼就是當前讀,那麼其實就須要加上S鎖。這裏發現惟一鍵已經存在，這個時候執行update就會被兩個事務的S鎖互相阻塞，從而造成上面的循環等待條件。

小提示: 在MVCC中，當前讀和快照讀的區別:當前讀每次須要加鎖（可使共享鎖或者互斥鎖）獲取到最新的數據，而快照讀是讀取的是這個事務開始的時候那個快照，這個是經過undo log去進行實現的。

這個就是整個死鎖的緣由，能出現這種死鎖的還有一個狀況，就是同一時間來三個插入操做，其中先插入的那個事務若是最後回滾了，其他兩個事務也會出現這種死鎖。

解決方案

這裏的核心問題是須要把S鎖給幹掉，這裏有三個可供參考的解決方案:

• 將RR隔離級別，下降成RC隔離級別。這裏RC隔離級別會用快照讀，從而不會加S鎖。
• 再插入的時候使用select * for update,加X鎖，從而不會加S鎖。
• 能夠提早加上分佈式鎖，能夠利用Redis,或者ZK等等，分佈式鎖能夠參考個人這篇文章。聊聊分佈式鎖

第一種方法不太現實，畢竟隔離級別不能輕易的修改。第三種方法又比較麻煩。因此第二種方法是咱們最後肯定的。

總結

說了這麼多，最後作一個小小的總結吧。排查死鎖這種問題的時候有時候光看死鎖日誌有時候會解決不了問題，須要結合整個的業務日誌，代碼以及表結構來進行分析，才能獲得正確的結果。固然上面有一些數據庫鎖的基本知識若是不瞭解能夠查看個人另外一篇文章爲何開發人員須要瞭解數據庫鎖。

最後這篇文章被我收錄於JGrowing-CaseStudy篇，一個全面，優秀，由社區一塊兒共建的Java學習路線，若是您想參與開源項目的維護，能夠一塊兒共建，github地址爲:https://github.com/javagrowing/JGrowing 麻煩給個小星星喲。

若是你們以爲這篇文章對你有幫助，你的關注和轉發是對我最大的支持，O(∩_∩)O: