（本文為了方便，英文關鍵詞都都採用小寫方式，相關知識點會簡單介紹，爭取做到可以獨立閱讀）

文章開始我會先介紹本文需要的知識點如下：

• innodb的聚簇索引（聚集索引）和非聚簇索引（二級索引、非聚集索引）的知識
• innodb的隔離級別（isolation level）
• 簡單的sql知識（能讀懂sql語句）
• MVCC（Multi-Version Concurrent Control）多版本併發控制
• 資料的髒讀、幻讀（如果有時間會詳細講一下髒讀如果沒時間，網上講這個地方的也很多）

問題1：讀有幾種模式、加鎖有幾種方式

我們先看一個mysql表和幾條語句表名稱：my_table  搜尋引擎：innodb表結構：

1. select * from my_table where id = 1;
 

2. select * from my_table where id = 1 lock in share mode;

3. select * from my_table where id = 1 for update;

4. update my_table set address = 'tianjin' where id = 1;

先說隔離級別，mysql隔離級別分為四種：未提交讀（read uncommitted）、提交讀（read committed）、重複讀（repeatable read）、序列化（serializable）其中mysql預設的隔離級別為重複讀（repeatable read

），以下簡稱為rr，本文也只介紹這種模式

讀的模式分為兩種：

• 快照讀（snapshot read）
• 當前讀（current read）

我們先來了解一下MVCC：MVCC是為了實現資料庫的併發控制而設計的一種協議。與其相對的事LBCC即基於鎖的併發控制（Lock-Based Concurrent Control）。要實現資料庫的併發訪問控制，最簡單的做法就是加鎖訪問，即讀的時候不能寫（這個讀為當前讀，後面介紹。允許多個執行緒同時對想讀的內容加鎖，即共享鎖或叫S鎖），寫的時候不能讀（只能有一個執行緒對同一內容進行寫操作，即排它鎖，X鎖）。這樣的加鎖訪問，其實並不算是真正的併發，或者說它只能實現併發的讀，既讀寫序列化，這樣就大大降低了資料庫的讀寫效能。LBCC是四種隔離級別中級別最高的Serialize隔離級別。MVCC對比LBCC它的最大好處便是，讀不加鎖，讀寫不衝突。在MVCC中，讀操作可以分成兩類，快照讀（Snapshot read）和當前讀（current read）。快照讀，讀取的是記錄的可見版本（可能是歷史版本，即最新的資料可能正在被當前執行的事務併發修改），不會對返回的記錄加鎖，如上面的sql語句1；而當前讀，讀取的是記錄的最新版本，並且會對返回的記錄加鎖，保證其他事務不會併發修改這條記錄。如上面的sql語句2,3,4。不同的是2加的是s鎖，3、4加的是x鎖，insert加的也是x鎖。注：MVCC只在RC和RR兩個隔離級別下工作，其他兩個隔離級別都和MVCC不相容

加鎖的方式：（未涉及意向鎖）

先看一個sql語句

update my_table set name ='zhang' where id = 1;

假設id為主鍵：此條sql執行的時候會給此行資料加x鎖，如下圖

mysql的innodb預設的隔離模式為RR模式，既可重複讀，Innodb的RR隔離級別保證對讀取到的記錄加鎖 (記錄鎖)，同時保證對讀取的範圍加鎖，新的滿足查詢條件的記錄不能夠插入 (間隙鎖)，因此不存在幻讀現象。但是標準的RR只能保證在同一事務中多次讀取同樣記錄的結果是一致的，而無法解決幻讀（不保證在事務中出現）問題。Innodb的幻讀解決是依靠MVCC的實現機制做到的。其他模式以後有時間再加在這裡不對其他模式做講解。這裡因為id為主鍵，innodb中在主鍵上存在聚簇索引，其他的索引均為二級索引，這裡做一下簡單介紹聚簇索引：在innodb儲存引擎中，主鍵的存在至關重要，及時你不為表設定主鍵，儲存引擎也會隱式的定義一個主鍵，只是對使用者來說透明。之所以說他重要，是因為聚簇索引的儲存是和資料儲存在一起的，而聚簇索引的資料就是資料儲存的順序。如果需要查詢的資料是連續的，那麼按照聚簇索引查詢到的資料位置也是連續的，只需要按順序讀取就可以。對於聚集索引，葉子結點即儲存了真實的資料行，不再有另外單獨的資料頁（這裡和後面的二級索引有區別，二級索引的葉子節點指向資料頁資料行的邏輯指標，需要按照指標再去檢索資料）。 在一張表上最多隻能建立一個聚集索引，因為真實資料的物理順序只能有一種。二級索引：表資料儲存順序與索引順序無關。對於非聚集索引，葉結點包含索引欄位值及指向資料頁資料行的邏輯指標，其行數量與資料錶行資料量一致。看上面的sql語句，或者看之前的幾條sql，這個語句執行的時候會給這條記錄加x鎖，這時候如果其他事務中的語句也在進行鎖的操作（既更新、插入或者刪除，以及2語句當前讀操作加的s鎖）就會造成鎖爭用（innodb出現鎖爭用的時候處理方式為回滾超時獲取不到鎖的事務）。我們先按照上面四條語句兩條併發時的相互影響的情況來情況1：id為主鍵

1. select * from my_table where id = 1;

2. select * from my_table where id = 1 lock in share mode;

我們上面說過，語句1為快照讀，對其他的讀或者寫沒有影響。所以這兩條語句並行時，1讀快照，2為語句加s鎖。

select * from my_table where id = 1 lock in share mode;

情況2：id為主鍵

2. select * from my_table where id = 1 lock in share mode;

3. select * from my_table where id = 1 for update;

其中語句2加s鎖，3加x鎖（在資料被加s鎖的時候，其他的給這條想要讀取這條記錄也需要給這條記錄加s鎖，這就是為什麼s鎖是共享鎖。此時是不允許再給這條記錄加x鎖的）兩種鎖是不能同時存在在一條記錄上的。所以兩條語句不能併發執行。情況3：id為主鍵

3. select * from my_table where id = 1 for update;

4. update my_table set address = 'tianjin' where id = 1;

這種情況下兩條語句都需要給資料加x鎖，所以顯然不能併發執行。

下面我們來討論一下id不為主鍵的情況

id若不為主鍵，則不能使用聚簇索引，而在innodb中有一下幾種情況

• 二級唯一索引
• 二級不唯一索引
• 沒有索引

由於只要不是快照讀則一定會加鎖，我們已經瞭解了鎖的形式，則不難明白不論是先加x鎖還是s鎖哪一種，都一定不能再加另一種鎖，所以我們下面只分析加鎖的方式情況4：假設id為二級唯一索引（unique）

4. update my_table set address = 'tianjin' where id = 1;

這裡很明顯需要加x鎖，但是這裡的加鎖和id為主鍵（索引為聚簇索引）的情況加鎖不完全一樣，會稍微複雜一點。這個時候我們需要對索引知識有一定的瞭解，上面說過二級索引中的葉子節點儲存的除了索引資訊還有到實際資料的邏輯指標，也就是說我們需要現在二級唯一索引中查詢到這條記錄的邏輯指標，然後通過指標去查詢到資料實際的儲存位置並給這條資料加鎖。注意，這裡的加鎖應該是加在了索引上和資料本身上（或者說是聚簇索引上也可以，因為兩者是儲存在一個結構中的，而innodb中二級索引葉子中的邏輯指標並不是資料儲存的實體地址，而是主鍵值）而不只是二級唯一索引上。如果想用好innodb，他的索引結構是必須要學習的，如果以後有時間會詳細介紹。情況5：age為二級非唯一索引，id為主鍵

5. update my_table set address = 'tianjin' where age = 25;

此種情況比前一種情況更特殊，因為情況3和4都只能找到一條記錄，只需要對這條記錄加鎖，則不會發生結果集被修改的情況。但是如果age為二級非唯一索引，我們看到如下表格中有兩條記錄age=25
如果我們在update的過程中，有一個使用者插入了一條age也為25的資料，那麼就是發生一種現象，你明明更新了所有的age=25的資料，但是執行完了卻有一條資料沒有更新的幻覺，這就是幻讀（可以自行查詢資料，避免本文過長）。這個時候顯然只給查找出的資料加鎖是解決不了這個問題的。所以就有了gap鎖（間隙鎖字面上可能更好理解）這裡需要畫圖大家理解一下：
如圖這裡在age為25的有兩個 ，id分別為1和3。我們在修改執行上面語句的時候，如果沒有gap鎖，則可能發生一種情況：另一個事務執行如下語句

update my_table set age=25 where id=2;

則發生幻讀現象。gap鎖可以防止在語句或者事務執行過程中有滿足條件的記錄插入進來造成幻讀。所以說在此種情況下，除了給滿足條件的二級索引和資料（或聚簇索引）加x鎖之外還要給相關的間隙加鎖。可以理解為這個加gap鎖是在二級索引的範圍內防止新的索引項加入，因為二級索引本身也是有序的。

情況6：age上無索引，id為主鍵

5. update my_table set address = 'tianjin' where age = 25;

這種情況下，所有記錄都被加上了X鎖，每條記錄間的間隙(GAP)也同時被加上了GAP鎖。在實際情況中可能sql更復雜，如果用到了其他列索引，mysql會按照索引順序篩選結果，也許並不會進行全表加x鎖和gap鎖。