2019.10.05 15:20:16字數 543閱讀 7
隔壁同事大佬
專案用的mysql資料庫引擎是innodb，資料庫的行鎖、表鎖是通過innodb使用表的索引來實現的。那麼就先查詢一下innodb的狀態：
show engine innodb status;------------------------
latest detected deadlock
------------------------
2019-08-21 12:08:13 7fb595c29700
*** (1) transaction:
transaction 63912726, active 0 sec updating or deleting
mysql tables in use 1, locked 1
lock wait 3 lock struct(s), heap size 1184, 2 row lock(s), undo log entries 1
mysql thread id 1587325, os thread handle 0x7fb55ee77700, query id 87233990 210.22.120.186 root updating
create_time='2011-08-20 17:54:56.0',
update_time='2011-08-21 12:08:14.468',
user_id=8,
job_status='done',
rerun=0,
merchant_id='asd',
loan_id=502,
`name`='autotest_0815100043938',
phone_number='1234567890',
`source`=0 where id=1163751259396098
*** (1) waiting for this lock to be granted:
record lock, heap no 167 physical record: n_fields 2; compact format; info bits 0
0: len 3; hex 50414e; asc pan;;
1: len 8; hex 901e52e11885c002; asc r ;;
*** (2) transaction:
transaction 63912725, active 0 sec starting index read
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1184, 2 row lock(s)
mysql thread id 1587327, os thread handle 0x7fb595c29700, query id 87233988 210.22.120.186 root creating sort index
*** (2) holds the lock(s):
record lock, heap no 167 physical record: n_fields 2; compact format; info bits 0
0: len 3; hex 50414e; asc pan;;
1: len 8; hex 901e52e11885c002; asc r ;;
*** (2) waiting for this lock to be granted:
record lock, heap no 28 physical record: n_fields 17; compact format; info bits 0
0: len 8; hex 901e52e11885c002; asc r ;;
1: len 6; hex 000003ceb3a3; asc ;;
2: len 7; hex 330000801d021e; asc 3 ;;
3: len 18; hex 363533313237313938363037333034383637; asc 653127198607304867;;
4: len 5; hex 99a3dc9e76; asc v;;
5: len 8; hex 80000000000006f2; asc ;;
6: len 5; hex 99a3dc9e76; asc v;;
7: len 3; hex 50414e; asc pan;;
8: len 1; hex 80; asc ;;
9: sql null;
10: len 20; hex 416d62696c447569742d47504d65726368616e74; asc ambilduit-gpmerchant;;
11: len 8; hex 8000000000001426; asc &;;
12: len 13; hex 4275646920536574696177616e; asc budi setiawan;;
13: len 13; hex 30383133323035313037323233; asc 0813205107223;;
14: sql null;
15: sql null;
16: len 4; hex 80000002; asc ;;
*** we roll back transaction (2)
在日誌中可以找到最近一次死鎖的日誌資訊：
------------------------
latest detected deadlock
------------------------
holds the lock(s): 當前事務持有的鎖資訊
waiting for this lock to be granted: 當前事務嘗試獲取的鎖資訊
解決這個問題：
根據產生的原因，使用for update來操作行鎖時，最簡單的辦法是直接使用主鍵索引。但是因為功能的需求是獲取明細狀態job_status為pan的第一條，因此sql修改為如下來滿足只根據主鍵索引來進行行鎖：
以上就是我這次遇到死鎖的排查過程和思考過程，如有遺漏或錯誤的地方，歡迎指正出來。謝謝！
記一次mysql死鎖問題
場景 innodb下不同的事務進行更新和插入操作導致資料庫死鎖，如下，在批量插入之前，進行了邏輯刪除操作，這段 在併發情況下出現死鎖 堆疊異常 deadlock found when trying to get lock try restarting transaction 更新操作sql 批量插入...
記一次線上問題排查
這次線上問題來的比較突然，影響也大，用部落格記錄下整個過程，也當作是對這次事故的一次總結歸納。day1 2018年06月21號上午10點，收到運營同事通知，http com api 訪問量劇增，日誌量達到80g 天，而且有上公升趨勢。運營同事讓我們排查，這種訪問是否正常。運營統計訪問量 收到通知後立...
記一次問題排查心得
平時程式執行的好好的，昨天收到一則使用者上報，在xp系統下面，程式啟動後彈出 應用程式正常初始化 0xc0150002 失敗，請單擊確定，終止應用程式 遇到這個問題後，在自己的xp虛擬機器裡面呼叫一把，果然也出現這個問題，接下來記錄解決這個問題的全過程。然後就是各種安裝 解除安裝 檢測組合情況，最後...