最近資料庫的學習都是基於InnoDB儲存引擎的，這一篇去學習第6章鎖的部分。

之前有一篇是關於資料庫ACID是基於什麼保證的，ACD都分析過了，今天關於I-隔離性資料庫中是基於鎖來保證的。

1. lock 和latch

latch主要保證併發執行緒操作臨界資源的正確性，沒有死鎖檢測的機制。

lock主要針對事務，鎖定包括表，頁，行，在commit或者rollback後釋放。存在死鎖機制。

2. 鎖的型別

2.1 InnoDB存在兩個行級別的鎖：

S Lock（共享鎖），允許事務讀一行資料。

X Lock（排他鎖），允許事務刪除或者更新一行資料。

注意，InnoDB同樣也支援表級別的S和X鎖，不要誤認為S和X鎖就只是針對行的。

共享鎖預設是並存的，但是共享鎖和排他鎖之間不能共存。

2.2 InnoDB也存在額外的鎖方式-意向鎖：

意向鎖的級別是表級別，分為兩種：

IS Lock（意向共享鎖），事務想要獲得一張表中某幾行的共享鎖。

IX Lock（意向排他鎖），事務想要獲得一張表中某幾行的排他鎖。

關於此圖有幾點需要特別注意的，不然會影響你的認知：

IS/IX/S/X在此處都是針對的表級別在討論，不要認為此處的S和X是說的行級別，受這個影響的人會對加鎖的過程感到疑惑的，可能大家都是受了翻譯書的影響，因為，書中在介紹這一個圖是是這麼說的，原文如下，注意文中說的故表級意向鎖和行級鎖的相容性如下，這是錯誤的說法。

為什麼我說這麼說是錯誤的？看下面一個簡單的例子：

1.SessionA 請求table IX（IX是mysql自動請求的，IS也是一樣）--成功，SessionB 請求table IX -成功。

2.SessionA 請求某一行的 X，發現已經有其他Session有IX了，根據圖的說法是衝突了。

3.同理SessionB也是一樣。

那麼問題來了：兩個不同的事務去更新同一個表中的不同的資料時還會受到鎖的影響嗎？

根據圖上的說法，會的呀，你看嘛，不是說衝突了嗎？？？？？？？？

一切的原因都是因為我上面標註的那句話是錯誤，導致了讀者對於這個概念的錯誤理解，而且我發現Mysql-InnoDB內幕詳解中錯誤的說法還存在於很多地方，希望大家讀的時候要頭腦清醒。

我們在2.1裡面也說了S和X鎖同樣也是存在表級別的。來看下面一句話的截圖：

總結一下：

IX，IS是表級鎖，不會和行級別的X，S衝突。只會和表級別的X，S衝突。比如說alter操作，drop操作，lock操作是不是對於書裡那句話很諷刺啊，說實話我看的時候也是一臉懵逼，這什麼時候出現了這個概念了？比較的竟然是表級別和行級別的。

那麼有了這個理解，對於上面的例子的第2部是不是就說的通了？可以正常獲取到X鎖，不衝突。

理解到此，意向鎖的作用到底是幹嘛的呢？同樣用例子來理解：

1.SessionA 鎖住了table中某一行，存在了S行鎖。

2.SessionB 申請整個table的X鎖。假設申請成功了，注意這邊只是假設成功。

3.SessionB在理論上能進行某一行的修改了，但是此時SessionA是存在了S鎖的，衝突了。

因此資料庫為了去解決這種衝突的造成，需要讓Session的申請被阻塞，直到SessionA釋放出來。需要怎麼判斷？

步驟1：判斷表是否被其他事務用表鎖鎖住。

步驟2：判斷表中某一行是否被鎖住。（但是如果需要判斷某一行的話，太費力了，需要掃描很多資料）

為了解決這個問題，引出了意向鎖，如果有意向鎖的話，那麼步驟2不需要去掃描表中很多資料，只要判斷當前是否存在IS鎖就行（因為例子裡SessionA獲得是行鎖S，因此資料庫會自動幫助我們獲取到表級IS鎖）。

3. 一致性非鎖定讀（普通讀）

我們知道，在一般使用時，如果當前事務正在修改某一個數據，那麼另一個事務還是可以正常讀取到這個資料，不會因此而等待，此時讀取到的資料其實是一份快照資料。這種技術成為多版本控制（MVCC）。

那麼它是怎麼讀取到的呢？之前有了undo和redo的學習，我們知道MVCC是通過undo實現的，此時讀的資料其實是讀取的undo log內的快照資料，也變相的說明資料其實不是最新的。

mysql在讀已提交和可重複讀的隔離級別下使用的都是非鎖定的一致性讀，其實這個概念之前在學習postgres時已經有了解，只是說法沒有這麼專業而已，傳送門1。

讀已提交：讀取的是select語句執行時的資料，因此會存在不可重複讀和幻讀的問題。

可重複讀：讀取的是事務開始時的資料，因此不可重複讀解決了，但是幻讀不能避免（InnoDB也有優化，可以解決幻讀，稍後講解）。

4. 一致性鎖定讀（當前讀）

叫的很專業，其實大家也都見過............通俗一點就是顯式的加鎖，控制住讀取出來的資料。

4.1 select ... for update（加X行鎖）

4.2 select ... lock in share mode（加S行鎖）

小測試模組：

lock in share mode 

1. 兩個不同的Session執行lock in share mode時。SessionA和SessionB的讀取沒有問題，但是當SessionA再想去更新這一條記錄時發現當前資料被SessionB鎖住了，因此它必須等到SessionB釋放掉鎖之後才能正常更新。所以對於這種存在併發場景時還是需要用 for update。

2. 只有一個Session時，可以正常更新。

for update

當前資料為下面：

其實我們如果想要唯一併鎖定資料而且還要更新的話，最好是採用select ..for update的方式。這種方式其實也是解決多執行緒更新問題的一種方式，還有一種就是在程式內通過Java層面的鎖去解決，一個道理。

5. 鎖的實現演算法

5.1 Record Lock（以下簡稱RL）：單行鎖定

5.2 Gap Lock（以下簡稱GL）：範圍鎖定，不包括當前行

5.3 Next-Key Lock（以下簡稱NKL）：Record+Gap，鎖定一個範圍，包括範圍本身。

RL鎖住的是索引記錄，因此如果建立的時候沒有指定索引，會選擇一個隱式主鍵。

NKL鎖住的是範圍加本身，例如，存在索引10,11,13,20。那麼會被分成(-無窮,10],(10,11],(11,13],(13,20],(20,+無窮)。

其實從書中的觀點可以得出一些結論，就是InnoDB的鎖都是基於索引存在的。如果沒有索引的話，不存在所謂的加行鎖。

此篇文章不去深入追究sql語句加何種鎖的問題，只探討一些專業講解，後篇會去逐一學習。傳送門。

在RR（可重複讀）的隔離機制下，mysql是解決了幻讀的問題，那麼它是怎麼控制住的呢？就是採用的NKL的加鎖方式，因為NKL中的GL演算法控制住了在併發事務下可能會將資料加在同一範圍內，從而導致RR級別下讀出多的條數，這也就是為什麼幻讀是針對條數。

那麼可以顯示的關閉GL：

1.隔離機制改成RC（讀已提交）。

2.引數innodb_locks_unsafe_for_binlog設定為1。