mysql 事務、死鎖問題復現：
第乙個事務刪除並插入，未提交；
begin;delete
from t_option_value_rel_resource where field_id = 1 and data_id = 1
;insert into `t_option_value_rel_resource`(`id`, `field_id`, `data_id`, `business_type`, `code`) values (uuid_short(),
1, 1, '
02', '01'
);commit;
第二個事務刪除，等待死鎖。
begin;delete
from t_option_value_rel_resource where field_id = 1 and data_id = 2
;commit;
原因：
事務1要對乙個已被間隙鎖控制的記錄進行插入意向鎖錄入，遂進入阻塞等待間隙鎖釋放，而恰巧另乙個事務也同樣要對乙個被間隙鎖控制的記錄進行插入意向鎖錄入，阻塞等待，當兩個事務間隙鎖碰巧有交集時就進入了死迴圈最後死鎖。
意向鎖：
如果對某乙個節點加意向鎖，就表明它的下層節點正在被加鎖。
記錄鎖：
指where的條件中使用索引作為條件，查出來的一條資料中的索引項會加鎖。
間隙鎖：
記錄鎖中間的資料會加鎖。
解決方案：
方案一：去掉事務，速度慢
可能會產生髒資料，產生髒資料的地方，再次匯入可以被覆蓋掉。
方案二：降低隔離級別為rc，避免間隙鎖（降級後會有不可重複讀和幻讀問題）。
不可重複讀:
如果事務a按一定條件搜尋，期間事務b刪除了符合條件的某一條資料，導致事務a再次讀取時資料少了一條。
幻讀:
事務a按照一定條件進行資料讀取，期間事務b插入了相同搜尋條件的新資料，事務a再次按照原先條件進行讀取時，發現了事務b新插入的資料。
方案三：設定innodb在rr級別下不使用間隙鎖（關閉後會有幻讀問題）。
innodb_locks_unsafe_for_binlog = 1
mysql 事務死鎖問題
花了一天時間，問題終於解決了，超有成就感。問了一下用過mysql的同事，他分析事務死鎖的原因可能是表中資料量太大，update語句的查詢條件沒有建索引，導致事務需要掃瞄全表 此時會鎖表 這個原因倒是跟我的情況很相似，發生死鎖的事務裡確實有根據普通建更新記錄的語句。我查了一下資料量，測試環境200多條...
mysql事務死鎖 MySQL事務 死鎖
一 概念 多個事務在同一資源上互相占用形成迴路。這就是死鎖 基本命令 檢視是否自動提交事務 show variables like autocommit 設定事務是否自動提交 set autocommit 0 set autocommit 1 二 例子 create table user id bi...
mysql沒有事務死鎖 Mysql事務與死鎖
好久沒有寫部落格了，最近工作太忙了，真的是996icu呀。想找個機會跳出來。之後我要做到work life balance！當考慮的就是資料一致性的問題時我們用就應該想到mysql的事務。但是當我們使用事務時會有很多的坑，首先我們了解一下事務的隔離界別。1 事物的隔離級別 資料庫中有四種資料隔離級別...