@Transactionpublic void service(Integer id) {    delete(id);    insert(id);}

本篇文章中所有實驗用到的建表語句：

create table `test` (    `id` int(11) NOT NULL,    `num` int(11) NOT NULL,    PRIMARY KEY (`id`),    KEY `num` (`num`)) ENGINE = InnoDB;
insert into    testvalues(10, 10),(20, 20),(30, 30),(40, 40),(50, 50);

S 鎖之間不互斥，多個事務可以同時獲取一條記錄上的 S 鎖 

X 鎖之間互斥，多個事務不能同時獲取同一條記錄上的 X 鎖 

S 鎖和 X 鎖之間互斥，多個事務不能同時獲取同一條記錄上的 S 鎖和 X 鎖

當多個事務同時去 update 索引上同一條記錄時，都需要先獲取到該記錄上的 X 鎖，所謂的鎖也就是會在記憶體中生成一個資料結構來記錄當前的事務資訊、鎖型別和是否等待等資訊。下圖中就是 T1 和 T2 同時去更新 id = 30 的這行記錄，並且 T1 成功獲取到了鎖，其在記憶體中生成的鎖結構資訊欄位 is_wating 為 false，可以繼續執行事務的後續邏輯，而 T2 獲取鎖失敗，則生成的鎖結構資訊欄位 is_wating 為 true，阻塞等待 T1 上的鎖釋放。

圖2.  T1 和 T2 同時去更新 id = 30 的這行記錄示意

RECORD LOCKS space id 58 page no 3 n bits 72 index `PRIMARY` of table `test`.`t`trx id 10078 lock_mode X locks rec but not gapRecord lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0 0: len 4; hex 8000000a; asc     ;; 1: len 6; hex 00000000274f; asc     'O;; 2: len 7; hex b60000019d0110; asc        ;;

在上面這個場景中，session A 分別在 T1、T3 時刻進行了兩次範圍查詢，session B 在 T2 時刻插入了一條該範圍內的資料，如果 session A 能在 T3 時刻查詢出 session B 插入的資料，就說明發生了幻讀。此時只使用互斥鎖是無法解決幻讀的，因為 num = 12 的記錄在資料庫中還不存在，不能給其加上互斥鎖來防止 T2 時刻 session B 的插入。

引入了間隙鎖之後，session A 在 T1 時刻會給 id = 20 記錄生成一個 Gap Locks，之後 session B 在 T2 時刻想要插入記錄時，需要先判斷待插入位置的後一條記錄上是否存在 Gap Locks，很明顯此時 id = 20 的記錄上已經存在了 Gap Locks，那麼session B 就需要在 id = 20 的記錄上生成一個插入意向鎖，並進入鎖等待。

圖3.引入了間隙鎖後

RECORD LOCKS space id 133 page no 3 n bits 80 index PRIMARY of table `test`.`test` trx id 38849 lock_mode X locks gap before recRecord lock, heap no 4 PHYSICAL RECORD: n_fields 4; compact format; info bits 0 0: len 4; hex 8000001e; asc     30 ;; 1: len 6; hex 00000000969c; asc       ;; 2: len 7; hex a60000011a0128; asc       (;; 3: len 4; hex 8000001e; asc     ;;

間隙鎖雖然解決了幻讀問題，但因每次都會鎖住一段間隙，大大降低了資料庫整體的併發度，且因間隙鎖和間隙鎖之間不互斥，不同事務可以同時對同一間隙加上 Gap Locks，這也往往是各種死鎖產生的源頭。

在上面 Gap Locks 的例子中事務 1 加的就是 Next-Key Locks，即同時給 id = 20 的記錄加了 X 鎖和 Gap 鎖。

圖4.同時給 id = 20 的記錄加了 X 鎖和 Gap 鎖

在可重複讀隔離級別下，update 和 delete 操作預設都會給記錄新增 Next-Key Locks，Mysql 中 Next-Key Locks 的鎖日誌資訊為：lock_mode X。

RECORD LOCKS space id 58 page no 3 n bits 72 index `PRIMARY` of table `test`.`t`trx id 10080 lock_mode XRecord lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0 0: len 8; hex 73757072656d756d; asc supremum;;
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0 0: len 4; hex 8000000a; asc     ;; 1: len 6; hex 00000000274f; asc     'O;; 2: len 7; hex b60000019d0110; asc        ;

實驗模擬如下：

對於語句 select * from test where id = 25 for update 因當前表中不存在該記錄，在可重複讀隔離級別下，為了避免幻讀，會給 (20, 30] 間隙加上 Gap Locks。

從鎖日誌可以看出 session 1 給記錄 30 新增了間隙鎖(lock_mode X locks gap before rec)。

RECORD LOCKS space id 133 page no 3 n bits 80 index PRIMARY of table `test`.`test` trx id 38849 lock_mode X locks gap before recRecord lock, heap no 4 PHYSICAL RECORD: n_fields 4; compact format; info bits 0 0: len 4; hex 8000001e; asc     30 ;; 1: len 6; hex 00000000969c; asc       ;; 2: len 7; hex a60000011a0128; asc       (;; 3: len 4; hex 8000001e; asc     ;;

當 session 2 插入記錄 26 時，會在 B+ 樹中先定位到待插入位置，再判斷插入位置的間隙是否存在 Gap Locks，也就是判斷待插入位置的後一記錄 id = 30 是否存在 Gap Locks，如果存在需要在該記錄上生成插入意向鎖等待。

RECORD LOCKS space id 133 page no 3 n bits 80 index PRIMARY of table `test`.`test` trx id 38850 lock_mode X locks gap before rec insert intention waitingRecord lock, heap no 4 PHYSICAL RECORD: n_fields 4; compact format; info bits 0 0: len 4; hex 8000001e; asc    30 ;; 1: len 6; hex 00000000969c; asc       ;; 2: len 7; hex a60000011a0128; asc       (;; 3: len 4; hex 8000001e; asc     ;;

圖5.生成的鎖記錄示意

在對 Mysql 中的各種鎖結構有了一個清晰的瞭解之後，回過頭來再看看前面的線上問題：

@Transactionpublic void service(Integer id) {    delete(id);    insert(id);}

• 傳入的引數 id 在原資料庫中不存在
• 傳入的引數 id 在原資料庫中存在

本次主要會針對 id 記錄在原資料庫中不存在進行分析

因 id = 15 在資料庫中不存在，在 T1 時刻 session 1 會給其所在間隙的下一條記錄新增上 Gap Locks，又因 Gap Locks 不互斥， 在 T2 時刻 session 2 和session 3 都會同時獲取到 id = 20 的 Gap 鎖。

下圖中 tx: T1、T2、T3 分別代表 session 1、session 2 和 session 3。

圖6.

當在 T3 時刻 session 1 插入 id = 15 的記錄時，會判斷其插入位置的後一條記錄是否存在 Gap Locks，如果存在，則需要在該記錄上生成 Insert Intention Locks 並等待持有 Gap Locks 的事務釋放鎖。

圖7.

圖8.

在 T5 時刻 session 3 開始執行插入語句，此時同 T4 時刻，死鎖形成，session 1 生成的插入意向鎖正在等待 session 3 上的 Gap Locks 釋放，session 3 上生成的插入意向鎖正在等待 session 1 上的 Gap Locks 釋放，此時 session 3 回滾釋放所有鎖資源後，session 1 才可以最終執行成功。

圖9.

看看當時出現線上問題時，介面的呼叫量情況：

圖10.出現線上問題時介面的呼叫量

進一步在本地模擬 300 個執行緒併發執行，因人腦併發分析所有事務的執行情況的話會非常複雜，本次只以事務 1 為一個點來進行分析。

圖11.

因此對於未來在業務程式碼中存在相似邏輯的地方，一定要做好防重校驗，避免短時間記憶體在對同一行資料的先更新再插入的併發操作。同時在可重複讀隔離別下，更新和刪除操作預設都會新增 Next-Key Locks，間隙鎖的引入使得死鎖問題在併發情況下很容易出現，這也是在業務邏輯實現上需要考慮的問題。