MYSQL:1213 Deadlock問題排查歷程

mark下自己近期在電商開發中遇到的一個問題-數據庫死鎖及其排查過程。
先拋一個業務報錯日志做為這次梳理的開始



上圖是我接收到的錯誤報警,SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction,錯誤信息顯示我們業務中有一條數據庫操作遇到了死鎖情況。接下來就開始我們的追查之旅。

1.執行“show engine innodb status”獲取INNODB引擎當前信息(show engine innodb status 詳細介紹

------------------------

LATEST DETECTED DEADLOCK

------------------------

2017-01-04 09:25:17 7f553477d700

*** (1) TRANSACTION:

TRANSACTION 124378994, ACTIVE 0.007 sec starting index read

mysql tables in use 1, locked 1

LOCK WAIT 4 lock struct(s), heap size 1184, 8 row lock(s), undo log entries 7

LOCK BLOCKING MySQL thread id: 11573556 block 11572504

MySQL thread id 11572504, OS thread handle 0x7f56342fb700, query id 3368968901 10.44.182.0 shzfstore updating

UPDATE `sku` SET `quantity`=quantity-'1',`lock_stock`=lock_stock+'1',`sys_version`=sys_version+1 WHERE `id` = '15608' AND `quantity` >= '1' limit 1

*** (1) WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 393 page no 45 n bits 248 index `PRIMARY` of table `store_product`.`sku` trx id 124378994 lock_mode X locks rec but not gap waiting

Record lock, heap no 19 PHYSICAL RECORD: n_fields 19; compact format; info bits 0

......

*** (2) TRANSACTION:

TRANSACTION 124378995, ACTIVE 0.004 sec starting index read

mysql tables in use 1, locked 1

3 lock struct(s), heap size 1184, 2 row lock(s), undo log entries 1

MySQL thread id 11573556, OS thread handle 0x7f553477d700, query id 3368968902 10.172.221.117 shzfstore updating

UPDATE `sku` SET `quantity`=quantity-'1',`lock_stock`=lock_stock+'1',`sys_version`=sys_version+1 WHERE `id` = '15504' AND `quantity` >= '1' limit 1

*** (2) HOLDS THE LOCK(S):

RECORD LOCKS space id 393 page no 45 n bits 248 index `PRIMARY` of table `store_product`.`sku` trx id 124378995 lock_mode X locks rec but not gap

Record lock, heap no 19 PHYSICAL RECORD: n_fields 19; compact format; info bits 0

......

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 393 page no 43 n bits 240 index `PRIMARY` of table `store_product`.`sku` trx id 124378995 lock_mode X locks rec but not gap waiting

Record lock, heap no 81 PHYSICAL RECORD: n_fields 19; compact format; info bits 0

......

*** WE ROLL BACK TRANSACTION (2)

LATEST DETECTED DEADLOCK記錄了最近一次的死鎖情況。
2017-01-04 09:25:17時間跟我們接收到的報錯日志時間吻合。
上面還可以看出兩個事務之間發生鎖競爭時,給我們留下的部分數據
事務1
UPDATEskuSETquantity=quantity-'1',lock_stock=lock_stock+'1',sys_version=sys_version+1 WHEREid= '15608' ANDquantity>= '1' limit 1
事務2
UPDATEskuSETquantity=quantity-'1',lock_stock=lock_stock+'1',sys_version=sys_version+1 WHEREid= '15504' ANDquantity>= '1' limit 1
死鎖的兩個資源均被lock_mode X locks了

最后,mysql給了很重要的一個數據“WE ROLL BACK TRANSACTION (2)” MYSQL回滾了事務2。既然mysql回滾了事務2,那么肯定是事務2的語句觸發了死鎖,被mysql回滾了,也就是應該為報錯日志所記錄的那部分。同時,MYSQL執行了事務1,那么事務1的SQL語句肯定被記錄在BINLOG中了。

2.查看binlog日志,找出事務1所執行的語句

查找依據:

  • SQL語句,根據LATEST DETECTED DEADLOCK提供的死鎖時記錄的sql語句。
  • 線程ID(mysql的唯一標識): MySQL thread id 11572504
  • 執行時間(時間線):2017-01-04 09:25:17 7f553477d700

根據以上三個標識,以及BINLOG的起始標志“BEGIN、COMMIT”,幾乎可以100%確定事務1所包含的SQL語句。

binlog信息大致如下

#170104  9:25:17 server id 3194178605  end_log_pos 137170469 CRC32 0x1b6559de   Query   thread_id=11572504  exec_time=0 error_code=0
SET TIMESTAMP=1483493117/*!*/;
BEGIN
......
### UPDATE `store_product`.`sku`
### WHERE
###   @1=15504
###   @2=11516
###   @3=0.01
###   @4=120065
###   @5=109433
###   @6=19
### SET
###   @1=15504
###   @2=11516
###   @3=0.01
###   @4=120065
###   @5=109432
###   @6=20
# at 137172557
......
### UPDATE `store_product`.`sku`
### WHERE
###   @1=15608
###   @2=11551
###   @3=0.01
###   @4=120077
###   @5=109426
###   @6=19
### SET
###   @1=15608
###   @2=11551
###   @3=0.01
###   @4=120077
###   @5=109425
###   @6=20
......
COMMIT/*!*/;

3.還原事務2所包含的執行語句

事務1的語句找齊了,接下來找事務2的語句,還記得我們開頭提供的報錯日志嗎,那個日志里也詳細記錄了發起請求時的參數情況(截圖未展示),根據參數和我們處理業務的代碼,可以復現事務2所要執行的語句

BEGIN
......
### UPDATE `store_product`.`sku`
### WHERE
###   @1=15608
###   @2=11516
###   @3=0.01
###   @4=120065
###   @5=109433
###   @6=19
### SET
###   @1=15608
###   @2=11516
###   @3=0.01
###   @4=120065
###   @5=109432
###   @6=20
......
### UPDATE `store_product`.`sku`
### WHERE
###   @1=15504
###   @2=11551
###   @3=0.01
###   @4=120077
###   @5=109426
###   @6=19
### SET
###   @1=15504
###   @2=11551
###   @3=0.01
###   @4=120077
###   @5=109425
###   @6=20
......
COMMIT/*!*/;

根據兩個事務所執行的sql語句,目前可以還原死鎖產生的原因了

4.查看兩個事務執行語句的順序:

順序 事務1 事務2 說明
1 begin
2 begin
3 UPDATE sku
SET quantity=quantity-'1',
lock_stock=lock_stock+'1',
sys_version=sys_version+1
WHERE id = '15504' AND
quantity >= '1' limit 1
事務1 給 sku表 id 15504記錄上 X 鎖
4 UPDATE sku
SET quantity=quantity-'1',
lock_stock=lock_stock+'1',
sys_version=sys_version+1
WHERE id = '15608' AND
quantity >= '1' limit 1
事務2 給 sku表 id 15608記錄上 X 鎖
5 UPDATE sku
SET quantity=quantity-'1',
lock_stock=lock_stock+'1',
sys_version=sys_version+1 WHERE id = '15608' AND
quantity >= '1' limit 1
這里是關鍵,事務1想給sku表 id 15608上X鎖,發現被別人(事務2)上鎖了,等待鎖釋放
6 UPDATE sku
SET quantity=quantity-'1',
lock_stock=lock_stock+'1',
sys_version=sys_version+1
WHERE id = '15504' AND
quantity >= '1' limit 1
事物2打算給sku表id為15504記錄上 X 排它鎖,發現被其他事務上了,而且此事務居然還在等他提交,這時MYSQL立刻回滾事務2…(php發現MYSQL返回死鎖信息,記錄該信息到錯誤日志…發送回滾指令…mysql已經“幫”他回滾了…)
7 執行成功 事務1發現別人的鎖釋放了,獲得X鎖,執行成功
8 commit 事務1執行成功,記錄binlog日志

解決方案

  • 減小事務中的語句數量
  • 在業務中調整語句的執行順序,例如可以按照where條件中字段的大小進行一下排序,按照排序后順序執行,讓死鎖變為鎖等待。

相關補充

  • innodb的行鎖,鎖的是查詢條件中的索引字段,以及索引字段對應的primary key字段
最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容