MySql鎖種類

在innodb中，鎖的種類如下：

• Shared and Exclusive Locks（共享鎖和排他鎖）
• Intention Locks（意向鎖）
• Record Locks（記錄鎖）
• Gap Locks（間隙鎖）
• Next-key Locks（Gap Lock + Record Lock）
• Insert Intention Locks（插入意向鎖）
• AUTO-INC Locks（自增鎖）
• Predicate Locks for Spatial Indexes

Shared and Exclusive Locks

Innodb實現(xiàn)了標準的行級鎖，其中有兩種類型：

• 共享鎖：允許持有共享鎖的事務讀取該行記錄。
• 排他鎖：允許持有排他鎖的事務更新或者刪除該行記錄。

如果事務T1持有某行數(shù)據(jù)的共享鎖，那么另一個事務T1想獲取該行數(shù)據(jù)的鎖時：

• 共享鎖：T2會馬上獲得一個共享鎖，此時T1、T2都有該行數(shù)據(jù)的共享鎖。
• 排他鎖：T2不能馬上獲得排他鎖。

如果事務T1持有某行數(shù)據(jù)的排他鎖，那么其他事務都不能立刻獲得該行數(shù)據(jù)的共享鎖或排他鎖。其他事務需要等待T1釋放它所持有的該行數(shù)據(jù)的排他鎖。

Intention Locks

Innodb支持多粒度鎖，允許行鎖和表鎖共存。為了實現(xiàn)多粒度級別的鎖，innodb使用了意圖鎖。意圖鎖是表級別的鎖，它指示事務稍后需要表中的一行使用哪種類型的鎖（共享或排他）。

以下是兩種類型的意向鎖：

• 共享意向鎖：表明該事務計劃對某行數(shù)據(jù)設置一個共享鎖。
• 排他意向鎖：表明該事務計劃對某行數(shù)據(jù)設置一個排他鎖。

例如，select .... for share就設置了一個共享意向鎖，select .... for update就設置了一個排他意向鎖。

意向鎖的形為：

• 在一個事務獲取到某行鎖的共享鎖之前，它必須先獲得一個共享意向鎖或者更高級別的鎖（也就是排他意向鎖啦）。
• 在一個事務獲取到某行鎖的排他鎖之前，它必須先獲得一個排他意向鎖。

表級鎖類型的兼容性如下：

事務可以獲得與已經(jīng)存在的鎖兼容的鎖，不能獲得與已經(jīng)存在的鎖沖突的鎖。在有沖突的鎖被釋放之前，事務會一直等待。如果一個鎖的請求與已存在的鎖沖突并且因為有可能產(chǎn)生死鎖而不能被獲得，那么就會產(chǎn)生一個錯誤。

除了全表請求（如，lock table ... write）之外，意向鎖不會阻塞任何事物。意向鎖的主要目的就是表面有人正在對某行進行加鎖，或者正要鎖住表內(nèi)某行。

Record Locks

記錄鎖是對索引進行記錄的鎖。例如，select c1 from t where c1 = 10 for update 禁止了任何其他事務對c1 = 10的數(shù)據(jù)行進行插入，更新或者刪除。

記錄鎖總是對索引進行加鎖，即使該表沒有定義索引。如果表沒有自己定義索引，那么innodb就會定義一個隱式的聚集索引（hidden clustered index）并且對這個索引進行加鎖。

Gap Locks（為了防止幻讀）

間隙鎖是對一個索引間隙加鎖的鎖。如果索引間隙的范圍為(index1,index2)，那么就鎖住index1到index2之間的間隙，如果索引只有一個index，那么根據(jù)innoddb底層的B+樹的結構，假設index前面最近的一個索引為index1，后面最近一個索引為index2，那么就會鎖住index1到index2之間的間隙。

例如，select c1 from t where c1 between 10 and 20 for update 禁止了其他任何事物插入一行c1=15的數(shù)據(jù)行，無論是不是已經(jīng)有了一行c1=15的數(shù)據(jù)行，因為10-20這個間隙的值都被鎖上了間隙鎖。間隙可能會包含單個索引值或者多個索引值，甚至有可能是空的。

再如，假設表的數(shù)據(jù)如下：

SELECT * FROM t;
+------+
| age |
+------+
| 21 |
| 25 |
| 30 |
+------+

那么，當執(zhí)行select age from t where age = 25 for updata時，鎖住的就是21-30之間的間隙。

間隙鎖是在性能和并發(fā)之間權衡的一部分，在某些事務隔離級別會使用，在某些事務隔離級別不使用。

對于使用唯一性索引搜索唯一行的情況，不需要加上間隙鎖（這不包括使用聯(lián)合唯一索引而只搜索其中一部分的列數(shù)據(jù)的情況，在這種情況下確實會加上一個間隙鎖）。

例如，select * from t where id = 100 只會對id值為100的行使用一個記錄鎖（record lock），不管其他事務是否會在前面的間隙插入行。但如果id上沒有一個唯一索引，那么就會鎖住某個間隙。

innodb中的間隙鎖是“純粹抑制的”（purely inhibitive），這意味著他們的唯一目的是防止其他事務插入到間隙中。間隙鎖可以共存，一個事務使用間隙鎖并不會阻止另一個事務使用同一間隙上的間隙鎖。

可以通過將事務隔離級別設置為READ COMMITTED來禁用間隙鎖。在READ COMMITTED隔離級別下，間隙鎖在搜索和索引掃描中被禁用，只用于外鍵約束檢查和重復鍵檢查。

Next-Key Locks

Next-Key Lock是索引上的記錄鎖和鎖住該索引前面的間隙的間隙鎖的組合。

innodb通過對搜索和掃描索引時得到的索引加共享鎖或排他鎖來實現(xiàn)行級鎖。因此，行級鎖實際上是索引記錄鎖。索引記錄上的next-key鎖也會影響該索引記錄之前的間隙。也就是說，next-key鎖是由索引記錄鎖加上對索引之前的間隙加鎖的間隙鎖組成的。如果一個會話對索引中的記錄R有一個共享鎖或排他鎖，那么另一個會話不能再緊挨著索引順序的R之前的間隙插入一個新的索引記錄。

默認情況下，innodb引擎采取REPEATABLE READ事務隔離級別，此時，innodb使用next-key lock來防止幻讀。

Insert Intention Locks

插入意向鎖時一種由insert操作在行插入之前的間隙鎖類型。這個鎖表面了插入的意圖，如果插入到同一個索引間隙中的多個事務沒有插入到間隙中的相同位置，那么它們就不需要互相等待。假設有值為4和7的索引，有兩個事務分別像插入5和6，那么他們在插入數(shù)據(jù)之前都會鎖住4和7之間的間隙，但此時他們不會互相阻塞，而他們隨后會獲得5和6的排他鎖，因為是行鎖，所有依舊不會互相阻塞。

例如：

客戶端A創(chuàng)建一個包含兩個索引記錄(90和102)的表，然后啟動一個事務，對ID大于100的索引記錄獲取排他鎖。排他鎖包括記錄102之前的間隙鎖:：

mysql> CREATE TABLE child (id int(11) NOT NULL, PRIMARY KEY(id)) ENGINE=InnoDB;
mysql> INSERT INTO child (id) values (90),(102);

mysql> START TRANSACTION;
mysql> SELECT * FROM child WHERE id > 100 FOR UPDATE;
+-----+
| id  |
+-----+
| 102 |
+-----+

客戶端B開始一個事務，向間隙中插入一條記錄。事務在等待獲得排他鎖時接受一個插入意圖鎖：

mysql> START TRANSACTION;
mysql> INSERT INTO child (id) VALUES (101);

在客戶端A的事務提交之前，客戶端B的對應間隙的插入都不能被執(zhí)行。

AUTO-INC Locks

AUTO-INC是一種特殊的表鎖，當事務想插入一條自增行的時候使用。

例如，如果一個事務正在插入數(shù)據(jù)，任何其他事務如果也要插入，那么他們都必須等待當前事務插入完畢，這樣才能保證那個自增字段是連續(xù)的。

Predicate Locks for Spatial Indexes

InnoDB支持包含空間數(shù)據(jù)的列的空間索引。為了處理想要鎖住空間索引的鎖，next-key鎖無法實現(xiàn)REPEATABLE READ 或 SERIALIZABLE事務隔離級別的要求。多維數(shù)據(jù)沒有絕對的排序概念，因此不知道哪一個是下一個索引，也就無法獲得間隙鎖。

為了支持具有空間索引的表的隔離級別，InnoDB使用Predicate Locks。一個Predicate鎖包含每個維度的邊界，每次就鎖住這些邊界就可以了。

總結

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。