線上SQL超時場景分析-MySQL超時之間隙鎖 | 京東物流技術團隊

前言

之前遇到過一個由MySQL間隙鎖引發線上sql執行超時的場景,記錄一下。

背景說明

分佈式事務消息表:業務上使用消息表的方式,依賴本地事務,實現了一套分佈式事務方案

消息表名:mq_messages

數據量:3000多萬

索引:create_time 和 status

status:有兩個值,1 和 2, 其中99%以上的狀態都是2,表示分佈式事務全部已經執行完成,可以刪除。

消息表處理邏輯

1. 啓動一個獨立的定時任務,刪除status=2的歷史數據,具體的sql如下:

    delete from mq_messages where create_time<xxx and status=2 limit 200

2. 定時任務執行頻率:3分鐘跑一次任務,一個任務執行200次 刪除。這個條件基本上篩選出了90%以上的數據

業務邏輯:線上業務在執行時,不斷的往表裏插入status=1的數據,主鍵id隨着時間是遞增的

sql超時產生的場景

一次大型促銷活動流量峯值的時候,出現了一次數據庫連接被打滿的情況,初步定位是數據量太大了導致鎖表導致的。爲了防止數據庫連接被再次打滿,需要儘快的刪除狀態爲2的數據,手動執行定時任務,刪除數據,具體sql爲:

delete from mq_messages where status=2 limit 2000

三分鐘執行一次任務,一個任務執行200次刪除。

然後,數據庫連接馬上被打滿,數據庫掛了

覆盤分析

線上是否存在表鎖?

初始化表結構(簡化後的表結構)

CREATE TABLE `my_test` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `a` int(11) NOT NULL,
  `b` int(11) NOT NULL,
  `state` int(11) NOT NULL DEFAULT '1',
PRIMARY KEY (`id`),
KEY `a` (`a`),
KEY `state` (`state`) USING BTREE
) 
ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4;

存儲過程準備測試數據

DELIMITER $$
  CREATE PROCEDURE pro_copy_date()
  BEGIN
  SET @i=1;
  WHILE @i<=100000 DO
  INSERT INTO my_test VALUES(@i,@i,@i,1); 
  SET @i=@i+1;
  END WHILE;
END $$
call pro_copy_date();
UPDATE my_test SET state =2 WHERE id <= 99990;

驗證

1. 數據基本情況

表中一共有10萬條數據,只有後10條的state=1(id>99990)

2. 事務隔離級別可重複讀

3. 開啓一個事務A,並且不提交

執行 DELETE FROM my_test WHERE state =2 LIMIT 2000;

4. 開啓另一個事務B

• 更新id=2001的數據,可以更新成功

• 更新id=2000的數據,被阻塞

說明沒有表鎖

5. 開啓另一個事務C

• 插入狀態爲2的數據,可以插入成功

• 插入狀態爲0的數據,可以插入成功

• 插入狀態爲1的數據,被阻塞

說明state的1和2的間隙被鎖導致不能插入

結論

線上不存在表鎖,而是間隙鎖

間隙鎖

線上間隙鎖場景分析

表中state一共兩個值1和2。因此會產生三個間隙 (-∞, 1), (1, 2), (2, +∞) 和兩個孤值1和2。根據前開後閉原則,對應的臨建鎖區間爲 (-∞, 1], (1, 2],(2, +∞)

執行DELETE FROM my_test WHERE state =2 LIMIT 2000時,掃描到的行數爲(state=2, id=1)到(state=2,i d=2000)。state=2落在區間](1,2]。因此鎖住的範圍是(state=1,id=100000) 到 (state=2,id=2000),如圖所示:

對於線上場景鎖的範圍是(state=1, id=status爲1的最大id) 到 (state=2, id=要刪除的記錄中id的最大值)。由於線上只會插入state=1而且,id是遞增的。新插入的id是表的最大值,所以新插入的記錄一定會落在鎖區間,所以新插入的記錄都會被阻塞。

間隙鎖作用

解決幻讀

幻讀指的是一個事務在前後兩次查詢同一個範圍的時候,後一次查詢看到了前一次查詢沒有看到的數據行。

幻讀專門指的是新插入的數據。

在可重複讀隔離級別下,普通的查詢是快照讀,是不會看到別的事務插入的數據的。幻讀在“當前讀”下才會出現。innodb解決幻讀的方法,間隙鎖。

幻讀帶來的問題

新建測試表:

CREATE TABLE `my_test2` (
  `id` INT (11) NOT NULL,
  `b` INT (11) DEFAULT NULL,
  `c` INT (11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `c` (`c`)
) ENGINE = INNODB;

-- 插入測試數據
NSERT INTO my_test2  VALUES(0, 0, 0),(5, 5, 5),(10, 10, 10),(15, 15, 15);

測試sql 1

begin;
select * from t where b=5 for update;

這個語句會命中 b=5 的這一行,對應的主鍵 id=5,因此在 select 語句執行完成後,id=5 這一行會加一個寫鎖,這個寫鎖會在執行 commit 語句的時候釋放。

由於字段 b 上沒有索引,因此這條查詢語句會做全表掃描。那麼,其他被掃描到的不滿足條件的記錄上,會不會被加鎖呢?

假如只會在id爲5的記錄上加鎖:

 事務A 事務B 事務C
T1 BEGIN; SELECT * FROM my_test2 where b=5 FOR UPDATE; 結果(5,5,5)  
T2  UPDATE my_test2 SET b=5 WHERE id = 0; 
T3 SELECT * FROM my_test2 where b=5 FOR UPDATE; 結果(0,5,0)(5,5,5)  
T4   INSERT INTO my_test2(1,5,1)
T5 SELECT * FROM my_test2 where b=5 FOR UPDATE; 結果(0,5,0)(1,5,1)(5,5,5)  
T6 commit  



 事務A 事務B
T1 BEGIN; SELECT * FROM my_test2 where b=5 FOR UPDATE; 
T2  UPDATE my_test2 SET b=5 WHERE id = 0; UPDATE my_test2 SET c=5 WHERE id = 0;
T3 commit 

假如只會在id爲5的記錄上加鎖,會破壞事務A的加鎖聲明,即“把所有 b=5 的行鎖住,不準別的事務進行讀寫操作

 事務A 事務B 事務C
T1 BEGIN; SELECT * FROM my_test2 WHERE b=5 FOR UPDATE; UPDATE my_test2 SET c=10 WHERE b=5;  
T2  UPDATE my_test2 SET b=5 WHERE id = 0; 
T3   INSERT INTO my_test2(1,5,1)
T4 commit  

T1時刻: id=5的這行數據,的c的值改成了10,事務還沒提交,binlog還沒寫

T2時刻:id=0 這一行變成 (0,5,0), 變更寫入binlog;

T3時刻:id=1 這一行變成 (1,5,1), 變更寫入binlog;

T4時刻:事務A提交,寫入binlog。

此時主庫的數據爲(0,5,0),(1,5,1),(5,5,10)

因此binlog寫入的日誌爲:

UPDATE my_test2 SET b=5 WHERE id = 0;
INSERT INTO my_test2(1,5,1)
UPDATE my_test2 SET c=10 WHERE b=5;

從庫執行完成binglog後數據就變成了(0,5,10),(1,5,10),(5,5,10),因此出現了數據的不一致

出現數據不一致的原因,是只鎖了那一刻需要變更的行,並不能阻擋現有數據變成b=5

如果把掃描到的行全部加鎖會如何哪?由於b沒有索引,索引得掃描全表才知道那一行需要更新,所以表中的每一條記錄都會被鎖住。

 事務A 事務B 事務C
T1 BEGIN; SELECT * FROM my_test2 where b=5 FOR UPDATE; UPDATE my_test2 SET c=10 WHERE b=5;  
T2  UPDATE my_test2 SET b=5 WHERE id = 0; (block) 
T3   INSERT INTO my_test2(1,5,1)
T4 commit  

T1時刻: id=5的這行數據,的c的值改成了10,事務還沒提交,binlog還沒寫

T2時刻:id爲0的行被鎖住,不能更新,等待鎖釋放;

T3時刻:id=1 這一行變成 (1,5,1), 變更寫入binlog;

T4時刻:事務A提交,寫入binlog。

T5時刻:事務A已提交,id=0的鎖被釋放,事務B更新成功,變成 (0,5,0),寫入binlog

此時主庫的數據爲(0,5,0),(1,5,1),(5,5,10)

因此binlog寫入的日誌爲:

INSERT INTO my_test2(1,5,1)
UPDATE my_test2 SET c=10 WHERE b=5;
UPDATE my_test2 SET b=5 WHERE id = 0;

從庫執行完成binglog後數據就變成了(0,5,0),(1,5,10),(5,5,10),因此還是存在數據不一致

鎖定了查找過程中掃描的行,有效的避免了修改帶來的數據不一致問題。數據之間的間隙插入的數據依然會出現b=5的數據,因此要向解決這個問題我們還需在數據的間隙加鎖

 事務A 事務B 事務C
T1 BEGIN; SELECT * FROM my_test2 b=5 FOR UPDATE; UPDATE my_test2 SET c=10 WHERE b=5;  
T2  UPDATE my_test2 SET b=5 WHERE id = 0; (block) 
T3   INSERT INTO my_test2(1,5,1) (block)
T4 commit  

T1時刻: id=5的這行數據,的c的值改成了10,事務還沒提交,binlog還沒寫

T2時刻:id爲0的行被鎖住,不能更新等待鎖釋放;

T3時刻:間隙(0,5)被鎖住,不能插入等待鎖釋放;

T4時刻:事務A提交,寫入binlog。

T5時刻:事務A已提交,id=0的鎖被釋放,事務B更新成功,變成 (0,5,0),寫入binlog

T6時刻:事務A已提交,(0,5)的間隙鎖被釋放,事務C寫入成功,變成 (1,5,1),寫入binlog

此時主庫的數據爲(0,5,0),(1,5,1),(5,5,10)

因此binlog寫入的日誌爲:

UPDATE my_test2 SET c=10 WHERE b=5;
UPDATE my_test2 SET b=5 WHERE id = 0;
INSERT INTO my_test2(1,5,1)

從庫執行完成binglog後數據就變成了(0,5,0),(1,5,1),(5,5,10),完美解決了數據不一致

通過上面兩個情況分析,如果只鎖對應修改的行,會出現兩個問題

1. 破壞加鎖聲明

2. 數據的不一致性

幻讀的解決方法

通過上面案例分析,即使把所有的記錄都加上鎖,還是阻止不了新插入的記錄。行鎖只能鎖住行,但是新插入記錄這個動作,要更新的是記錄之間的“間隙”。因此,爲了解決幻讀問題,InnoDB 只好引入新的鎖,也就是間隙鎖 (Gap Lock)

間隙鎖,鎖的就是兩個值之間的空隙,表中一共有4條數據,因此會產生五個間隙 (-∞, 0), (0, 5), (5, 10), (10, 15), (15, +∞),在掃描確認要修改的行時,不僅僅要鎖住掃描到的行,兩邊的間隙也要加上鎖。

間隙鎖和行鎖合稱 next-key lock(鄰鍵鎖),每個 next-key lock 是前開後閉區間。因此上述情況會有五個鄰鍵鎖(-∞,0],(0,5],(5,10],(10,15],(15, +∞)

間隙鎖可以被多個事務同時加

間隙鎖和行鎖有區別,行鎖只能被一個事務加上,但是間隙鎖可以被多個事務加上。

如下圖:開啓兩個事務,

1. 事務A執行:SELECT * FROM my_test2 WHERE id=2 for UPDATE; 會鎖住(0,5)這個間隙。

2. 事務B執行SELECT * FROM my_test2 WHERE id=3 for UPDATE;,同樣也會鎖住(0,5)這個間隙,而且可以成功。

間隙鎖的目前是保護這個間隙不能插入數據,但他們不衝突。

加鎖規則

原則1:加鎖的基本單位是 next-key lock,next-key lock 是前開後閉區間。

原則2:查找過程中訪問到的對象纔會加鎖。

優化1:索引上的等值查詢,給唯一索引加鎖的時候,next-key lock 退化爲行鎖。

優化2:索引上的等值查詢,向右遍歷時且最後一個值不滿足等值條件的時候,next-key lock 退化爲間隙鎖。

唯一索引上的範圍查詢會訪問到不滿足條件的第一個值爲止

加鎖規則—等值查詢間隙鎖

事務A執行UPDATE my_test2 SET b=100 WHERE id =7;

根據原則1,加鎖的區間應該爲(5,10].

根據優化2,這是一個等值查詢 ,而 id=10 不滿足查詢條件,next-key lock 退化成間隙鎖,因此最終加鎖的範圍是 (5,10)。

因此:事務B的插入會被阻塞,事務C的更新可以成功

事務A:

事務B:

事務C:

加鎖規則—非唯一索引等值查詢

事務A執行SELECT id FROM my_test2 WHERE c=5 lock in share mode``;

根據原則1,加鎖的區間應該爲(0,5],由於c不是唯一索引還得往後掃描,因此(5,10]也會被加鎖。根據優化2,會退化成(5,10)。因此索引c上的鎖區間爲(0,10)。

由於這個查詢走的是索引覆蓋,並不需要去主鍵索引查數據,因此id=5的行並不會被鎖住 。

所以更新會成功,插入不會成功

事務A執行SELECT * FROM my_test2 WHERE c=5 lock in share mode;

由於 查詢全部的數據就需要,去主鍵索引上查找id=5的數據,根據原則2,id=5的這行數據也要被鎖住,因此更新會被阻塞。

注意,如果執行的語句爲SELECT id FROM my_test2 WHERE c=5 for UPDATE;雖然這個語句也會走索引覆蓋,但是用for update mysql會認爲你接下來要更新這行,因此順便會給id=5的這行加鎖。

加鎖規則—非唯一索引,存在等值

新插入兩條數數據(20,20,5)和(30,30,5)

執行sql: DELETE FROM my_test2 WHERE c=5 LIMIT 2;

根據加鎖原則,只會掃描c=5的數據,因此加鎖區間爲

(c=0,id=0) 到 (c=5,id=20)

INSERT INTO my_test2 VALUES(-1,0,0); //不阻塞

INSERT INTO my_test2 VALUES(1,0,0); //阻塞

INSERT INTO my_test2 VALUES(19,0,5); //阻塞

INSERT INTO my_test2 VALUES(21,0,5); //不阻塞

執行結果驗證:

數據庫底層實現博大精深,本文所述,根據線上場景進行了一些研究和探討,希望能爲相關場景提供一些啓示。文章中難免會有不足之處,希望讀者能給予寶貴的意見和建議。謝謝!

作者:京東物流 劉浩

來源:京東雲開發者社區 自猿其說Tech 轉載請註明來源

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章