花了一週時間，總算把mysql的加鎖搞清楚了，再也不怕間隙鎖和next-key了

接觸mysql都知道在mysql中有很多鎖，共享鎖（S）、排他鎖（X）、間隙鎖（gap）、next-key，當然還有意向鎖、表鎖等。今天不講別的，專門來看下innodb引擎下的鎖是什麼樣子的。

現在有這樣一條sql語句，你知道是什麼鎖嗎？

update t set name='1' where id=10;

可能會說是鎖住id=10的行鎖吧，沒錯行鎖是一定的，但鎖的是id=10還是其他。。。這個就犯難了。

其實不然，要判斷一條sql語句使用什麼鎖，不是憑猜測的，而是要有依據的。從下面幾個方面入手，

1、數據庫隔離級別；

2、數據庫索引；

3、使用到的索引；

判斷一條sql使用什麼鎖一定不能脫開上面的3條，否則說使用了什麼鎖都是毫無意義的，加什麼樣的鎖取決於要實現什麼目標，如果不是這個，那不加鎖豈不是更好。先來看下事務及索引。

一、事務及索引

1.1、事務

對於innodb引擎來說是支持庫事務的，事務有四大特性，分別是A（原子性）、C（一致性）、I（隔離性）、D（持久性）。

在隔離性中有四大隔離級別，分別是RU（讀未提交）、RC（讀已提交）、RR（可重複讀）、Serirable（可串行化）。四種隔離級別會影響加鎖的範圍，同時加鎖解決了相應隔離級別下出現的問題，比如幻讀、不可重複讀都可以通過加鎖解決。

1.2、索引

innodb使用B+樹作爲索引結構，索引可分爲聚集索引、非聚集索引。簡單點聚集索引就是索引和數據是在一起的，而非聚集索引則是索引和數據是分開的，正好分別對應主鍵索引、輔助索引。

在innodb引擎中主鍵索引是聚集索引，在索引的葉子節點中存儲的是整行數據；而在輔助索引節子點存儲的主鍵值。

如果一條sql走的是輔助索引，那麼要找到這條完整的數據，則必須再遍歷主鍵索引B+樹，讀取主鍵索引的葉子節點獲得到完整的整行數據。

innodb引擎的表最終都是通過一棵主鍵索引的B+樹來存儲數據的；輔助索引存儲的僅是索引列。

搞清楚了數據庫的隔離級別和索引後，再來看mysql中鎖的使用情況。

有這樣一張t_user表，其中id是主鍵，自增；u_code是唯一索引；u_name、u_address是一個輔助索引。

CREATE TABLE `t_user` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `u_name` varchar(100) DEFAULT NULL,
  `u_code` varchar(100) DEFAULT NULL,
  `u_age` varchar(100) DEFAULT NULL,
  `u_address` varchar(100) DEFAULT NULL,
  `interest` varchar(100) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `t_user_un` (`u_code`),
  KEY `index_name_address` (`u_name`,`u_address`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4;

二、RU/RC隔離級別

看下在RU（讀未提交）、RC（讀已提交）兩種隔離級別下的加鎖情況。

2.1、select

2.1.1、主鍵索引

2.1.1.1、主鍵-等值

select * from t_user where id=1 for update;

對id=1的記錄加X（排它）行鎖；如該行不存在不加鎖；

select * from t_user where id=1 in share mode;

對id=1的記錄加S（共享）行鎖；如該行不存在不加鎖；

2.1.1.2、主鍵-範圍

select * from t_user where id<=5 for update

數據中存在小於等於5的主鍵共有5條（1、2、3、4、5）數據，以此對這5條加X（排它）行鎖，其餘不加鎖；

select * from t_user where id<=5 in share mode;

數據中存在小於等於5的主鍵共有5條（1、2、3、4、5）數據，以此對這5條加S（共享）行鎖，其餘不加鎖；

2.1.2、唯一索引

2.1.2.1、等值

select * from t_user where u_code=001 for update;

對u_code=001的索引記錄加X（排它）行鎖，同時在對應的主鍵行上也要加X（排它）行鎖，如該行不存在不加鎖；

select * from t_user where u_code=001  in share mode;

對u_code=001的索引記錄加S（共享）行鎖，同時在對應的主鍵行上也要加S（共享）行鎖。如該行不存在不加鎖；

2.1.2.2、範圍

select * from t_user where u_code<=005 for update

針對上面的語句，我們猜想會走唯一索引，但其實不是的，使用explain看下

可以看到走的是全表掃描，所以這裏會給所有的主鍵行加X鎖，同時判斷是否滿足條件，對不滿足的會立即釋放X鎖。要想走唯一索引可以使用下面的語句，

explain select * from t_user 
force index(t_user_un)
where u_code <='009' for update 

這時的加鎖便是對滿足條件的u_code索引記錄加X（排它）行鎖，同時對對應的主鍵記錄加X（排它）行鎖；其餘不加鎖；

is share mode 也是同樣的道理，只不過加的是S鎖，不再演示。

 所有的更新都會表現在主鍵的B+樹索引上，爲了防止其他語句對數據進行修改，對主鍵行加鎖便是最好的選擇。

2.1.3、輔助索引

存在輔助索引(u_name,u_address)。

2.1.3.1、等值

select * from t_user where u_name='test3'  for update;

對u_name='test3'的索引記錄加X（排它）行鎖，同時在對應的主鍵行上也要加X（排它）行鎖，如該行不存在不加鎖；

select * from t_user where u_code=001  in share mode;

對u_code=001的索引記錄加S（共享）行鎖，同時在對應的主鍵行上也要加S（共享）行鎖。如該行不存在不加鎖；

2.1.3.2、範圍

select * from t_user where u_code<=005 for update

對滿足條件的u_code索引記錄加X（排它）行鎖，同時對對應的主鍵記錄加X（排它）行鎖；其餘不加鎖；

select * from t_user where u_code<=005 in share mode;

對滿足條件的u_code索引記錄加S（共享）行鎖，同時對對應的主鍵記錄加S（共享）行鎖；其餘不加鎖；

2.2、update

更新sql的加鎖情況和select的加鎖情況類似，區別在於更新的時候是否有索引列。

更新索引不包含索引列

看下面這個sql

update t_user set u_address='guangzhou' where id=4;

在主鍵行加X（排它）鎖。

在看下面這樣一條，

update t_user set u_address='guangzhou' where u_code='001';

該sql會命中唯一索引，索引在唯一索引記錄上會加X（排它）鎖，同時在唯一索引對應的主鍵記錄行也會加X（排它鎖）。

更新包含索引列

看下面這個sql

update t_user set u_code='003' where id=4;

在主鍵行加X（排它）鎖；另外由於u_code列是唯一索引，在u_code的索引上加X（排它）鎖。

在看下面這樣一條，

update t_user set u_name='test' where u_code='001';

該sql會命中唯一索引，索引在唯一索引記錄上會加X（排它）鎖，另外，u_name列命中輔助索引，在u_name的索引記錄上加X（排它）鎖，最好在唯一索引對應的主鍵記錄行也會加X（排它）鎖。

2.3、delete

delete語句的加鎖情況和相應的select的語句是一樣的，可根據情況具體分析；

 

RU/RC兩種隔離級別下給sql加的都是行鎖，不涉及範圍的鎖定。在RR下就不一樣了，因爲要解決幻讀和不可重複讀。

三、RR隔離級別

看下在RR（可重複讀）隔離級別下的加鎖情況。

3.1、select

3.1.1、主鍵索引

3.1.1.1、等值

select * from t_user where id=10 for update;

對id=1的記錄加X（排它）行鎖；

如該行不存在則會在這條不存在的記錄間加gap（間隙）鎖。看下面的數據

會在(7,12)間加gap鎖，防止其他事務執行insert操作，防止幻讀。

3.1.1.2、等值-share

select * from t_user where id=1 in share mode;

對id=1的記錄加S（共享）行鎖；如該行不存在則會在這條不存在的記錄間加gap（間隙）鎖，只不過這裏是s gap。

3.1.1.3、範圍-大於

數據是這樣的，

select * from t_user where id>=15 for update

數據中存在大於等於15的數據，對15加X（排它）鎖，對20，25，30，40加next-key，也就是(15,20]，(20,25]，(25,30]，(30,40]，(40,無窮)。

如果條件是‘>15’且15存在，則不會對15加X（排它）鎖，其他的和上面一樣。

如果15不存在，則加鎖情況是(13,15]，(15,20]，(20,25]，(25,30]，(30,40]，(40,無窮)。

在範圍（大於）條件下加了間隙鎖（gap），目的是阻止insert插入語句，解決幻讀問題。

3.1.1.4、範圍-小於

select * from t_user where id<=5 for update;

數據中存在小於等於5的主鍵數據，會對(1,4]，(4,5]，(5,6]加next-key。

如果不存在id=5的數據，則會找到離5最近的，加gap鎖。

3.1.2、唯一索引

3.1.2.1、等值

select * from t_user where u_code=001 for update;

對u_code=001的索引記錄加X（排它）行鎖，同時在對應的主鍵行上也要加X（排它）行鎖。如該行不存在不加鎖；

select * from t_user where u_code=001  in share mode;

對u_code=001的索引記錄加S（共享）行鎖，同時在對應的主鍵行上也要加S（共享）行鎖。如該行不存在不加鎖；

3.1.2.2、範圍

select * from t_user where u_code<=005 for update

針對上面的語句，我們猜想會走唯一索引，但其實不是的，使用explain看下

可以看到走的是全表掃描，所以這裏會給所有的主鍵行加next-key鎖，也就是會鎖住全部數據範圍。

要想走唯一索引可以使用下面的語句，

explain select * from t_user 
force index(t_user_un)
where u_code <='009' for update 

這時的加鎖便是對滿足條件的u_code索引記錄加next-key鎖，同時對對應的主鍵記錄加X（排它）行鎖；其餘不加鎖；

is share mode 也是同樣的道理，只不過加的是S鎖，不再演示。

3.1.3、輔助索引

 

下面的sql均會命中輔助索引(u_name,u_address)。

3.1.3.1、等值-存在

select * from t_user where u_name='3'  for update;

對u_name='test3'的索引記錄加next-key鎖，同時在對應的主鍵行上也要加X（排它）行鎖，加排它鎖的目的是方式update/delete；在下一個記錄test1上加gap鎖，加gap的目的是防止insert，綜上該條語句會鎖定(11,test1)範圍，也就是在執行insert的時候u_name不能再(11,test1)間。

主要是u_name不是唯一索引，爲了防止幻讀則必須在其在的範圍內(11,test1)加gap，另外對u_name=3所在的主鍵行加X鎖，防止的是對已存在的行update/delete；換句話說防止了insert這不就解決了幻讀，防止了update/delete這不就解決了不可重複讀。

3.1.3.2、等值-不存在

select * from t_user where u_name='4'  for update;

u_name=4不存在，會在(3,test1)間加gap鎖，也就是在insert的時候，不能插入在(3,test1)間的值，比如'31'、'a'等。防止執行insert操作，其他操作均可；

3.1.3.3、範圍-大於

select * from t_user where u_name>='3' for update

對滿足條件的3 test1 test2 加X（排它）鎖，對3 test1 test2命中的主鍵加X鎖；同時在(11,3)、(3,test1)、(test1,test2)、（test2,無窮）加gap防止insert。這裏有小夥伴會疑惑，爲什麼在(11,3)間有gap鎖，這是因爲u_name不唯一，在(11,3)間有可能插入u_name=3的數據。

3.1.3.4、範圍-小於

select * from t_user where u_name<='3' for update;

對滿足條件的1 11 3加X（排它）鎖，對1 11 3命中的主鍵加X鎖；同時在(無窮,1)、(1,11)、(11,3)、(3,test1)加gap防止insert。這裏有小夥伴會疑惑，爲什麼在(3,test1)間有gap鎖，這是因爲u_name不唯一，在(3,test1)間有可能插入u_name=3的數據。

3.2、update

更新操作分爲更新字段中是否包含了索引字段兩種情況。

3.2.1、不包含索引字段

update t_user set u_address where id=2;
update t_user set u_address where u_name>='007';

分析上面的兩個更新sql的加鎖情況，首先看where條件，和select  ... for update的情況是一樣的；其次u_address不是索引列所以不會額外加鎖。

3.2.2、包含索引字段

update t_user set u_name='000' where id=9;
update t_user set u_code='test001' where u_name='000';

上面的兩條更新sql，依然是先where條件，和select ... for update的情況是一樣的；其次由於u_name、u_code都會命中索引，所以會在索引上加鎖，u_name是輔助索引，會加gap鎖；u_code是唯一索引，會對test001加X（排它）鎖；

3.3、delete

3.3.1、主鍵

3.3.1.1、等值

delete from t_user where id=12;

主鍵的等值delete，會鎖定主鍵行，id=12不管是否存在都會鎖定12這個值，其他對該行的insert/update都會是X鎖。

3.3.1.2、範圍

delete from t_user where id<=6;

 會鎖定小於等於6的整個區間，不允許insert/update/delete

3.3.2、唯一索引

3.3.2.1、等值

delete from t_user where u_code ='007'

主鍵的等值delete，會鎖定主鍵行，id=12不管是否存在都會鎖定12這個值，其他對該行的insert/update都會是X鎖。

3.3.2.2、範圍

delete from t_user where u_code <='007'

 會鎖定唯一索引記錄小於等於007的區間，同時鎖定相應的主鍵行；

3.3.3、輔助索引

3.3.3.1、等值

delete from t_user where u_name='test'

這裏會命中輔助索引，所以和select...for update的加鎖是一樣的。同時還會對相應的唯一索引、主鍵索引加X鎖。

3.3.3.2、範圍

delete from t_user where u_name<='test'

和select ...for update的加鎖是一樣的。

四、Serializable隔離級別

serializable隔離級別下和RR級別下是一致的，另外serializable級別下的所有select都是徐雲加鎖的，加的是S鎖。

五、總結

本文重點分析了innodb引擎下各種sql的加鎖情況，瞭解sql的加鎖情況可以更好的幫助我們去理解sql的執行流程，理解mysql中的很多概念，看加鎖情況從“隔離級別”和“索引”兩方面去綜合分析。

推薦閱讀

花了半天時間，使用spring-boot實現動態數據源，切換自如

spring-boot集成mybatis真的很簡單嗎？

僅僅是調用第三方接口那麼簡單嗎？

參考：http://mysql.taobao.org/monthly/2018/05/04/