先看異常日誌
在乙個事物中既有update，又有select for update（意向排它鎖）
資料庫中，有user_id的索引和user_id與auth_type的聯合索引
session 1
session 2
begin;
begin;
update cre_auth_status set user_id='29507138388754432',auth_type=4,auth_status=2,update_time='2018-11-21 09:32:35.414' where (user_id='29507138388754432' and auth_type=2)
排它鎖，因為有單獨索引，將鎖
user_id='29507138388754432'
的相關資料表單鎖定。
update cre_auth_status set user_id='29507138388754432',auth_type=9,auth_status=2,update_time='2018-11-21 09:32:35.414' where (user_id='29507138388754432' and auth_type=9)
排它鎖pending
select id, user_id, basic_type, auth_type, auth_status, task_id, auth_time, expire_time, create_time, update_time from cre_auth_status where user_id = '29507138388754432' and basic_type =3 and auth_status =2 for update
需要等待
user_id='29507138388754432'
的資料釋放，鎖也是處於
pending
狀態，和
session2
爭搶鎖資源，進入死鎖。
select
時，user_id
的索引需要鎖住了
user_id=』 29507138388754432』
的資料，等待
session2
中的update
釋放，但是因為
session2
中的排它鎖是
pending
狀態，未
commit
，鎖等待中，進入死鎖
select id, user_id, basic_type, auth_type, auth_status, task_id, auth_time, expire_time, create_time, update_time from cre_auth_status where user_id = '29507138388754432' and basic_type =3 and auth_status =2 for update
死鎖出現異常，事物回滾
拿到鎖，正常流程往下走
解決方式：
將事物放在
update
裡，等待
update
結束之後，再進行
select
；去掉事物，事物在這裡屬於畫蛇添足。
@override
public
void
updateauthstatus(long userid,integer authtype,integer authstatus,string operatorgid,int
retrynum)catch(exception e)",e);
}
}
DDL導致的死鎖
mariadb galera cluster 中做ddl時會引起死鎖，但這個死鎖並不是由於併發導致的。而是galera cluster中特有的 坑 當在mariadb galera cluster中做ddl時，相關表的讀寫事務都會報死鎖的異常。error 1213 40001 deadlock fo...
SQL Server 死鎖問題的分析
一 什麼是死鎖？簡單來說，我和你，金鎖和銀鎖。我拿著金鎖，我需要再拿到銀鎖，才能完成任務，你拿著銀鎖，你需要再拿到金鎖，才能完成任務。我拿不到銀鎖，你拿不到金鎖，這就形成死鎖了。二 死鎖發生後，sql server怎麼處理？sql server內建有死鎖偵測和處理機制，每5s會檢測一次，如果有死鎖，...
windbg分析死鎖問題
如下 include include include using namespace std critical section cs db1 critical section cs db2 dword winapi threadproc lpvoid lpparam void main delete...