一、表級鎖、行級鎖、頁級鎖
資料庫鎖定機制簡單來說，就是資料庫為了保證資料的一致性，而使各種共享資源在被併發訪問變得有序所設計的一種規則。
MySQL資料庫由於其自身架構的特點，存在多種資料儲存引擎，每種儲存引擎的鎖定機制都是為各自所面對的特定場景而優化設計，所以各儲存引擎的鎖定機制也有較大區別。
MySQL各儲存引擎使用了三種型別（級別）的鎖定機制：表級鎖定，行級鎖定和頁級鎖定。
1、表級鎖
表級別的鎖定是MySQL各儲存引擎中最大顆粒度的鎖定機制。該鎖定機制最大的特點是實現邏輯非常簡單，帶來的系統負面影響最小。所以獲取鎖和釋放鎖的速度很快。
當然，鎖定顆粒度大所帶來最大的負面影響就是出現鎖定資源爭用的概率也會最高，致使併發度大打折扣。
使用表級鎖定的主要是MyISAM，MEMORY，CSV等一些非事務性儲存引擎。
2、行級鎖
行級鎖定最大的特點就是鎖定物件的顆粒度很小，由於鎖定顆粒度很小，所以發生鎖定資源爭用的概率也最小，能夠給予應用程式儘可能大的併發處理能力而提高一些需要高併發應用系統的整體效能。
雖然能夠在併發處理能力上面有較大的優勢，但是行級鎖定也因此帶來了不少弊端。
由於鎖定資源的顆粒度很小，所以每次獲取鎖和釋放鎖需要做的事情也更多，帶來的消耗自然也就更大了。此外，行級鎖定也最容易發生死鎖。
使用行級鎖定的主要是InnoDB儲存引擎。
3、頁級鎖
頁級鎖定是MySQL中比較獨特的一種鎖定級別。頁級鎖定的特點是鎖定顆粒度介於行級鎖定與表級鎖之間，所以獲取鎖定所需要的資源開銷，以及所能提供的併發處理能力也同樣是介於上面二者之間。
使用頁級鎖定的主要是BerkeleyDB儲存引擎。
4、總結
總的來說，MySQL這3種鎖的特性可大致歸納如下：
表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖衝突的概率最高，併發度最低；
行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖衝突的概率最低，併發度也最高；
頁面鎖：開銷和加鎖時間界於表鎖和行鎖之間；會出現死鎖；鎖定粒度界於表鎖和行鎖之間，併發度一般。
二、共享鎖、排它鎖
InnoDB 實現了標準的行級鎖，包括兩種：共享鎖（簡稱 s 鎖）、排它鎖（簡稱 x 鎖）。
對於共享鎖而言，對當前行加共享鎖，不會阻塞其他事務對同一行的讀請求，但會阻塞對同一行的寫請求。只有當讀鎖釋放後，才會執行其它事物的寫操作。
對於排它鎖而言，會阻塞其他事務對同一行的讀和寫操作，只有當寫鎖釋放後，才會執行其它事務的讀寫操作。
簡而言之，就是讀鎖會阻塞寫(X)，但是不會堵塞讀(S)。而寫鎖則會把讀(S)和寫(X)都堵塞
對於InnoDB 在RR(MySQL預設隔離級別) 而言，對於 update、delete 和 insert 語句， 會自動給涉及資料集加排它鎖（X）；
對於普通 select 語句，innodb 不會加任何鎖。如果想在select操作的時候加上 S鎖 或者 X鎖，需要我們手動加鎖。
-- 加共享鎖（S）
select * from table_name where ... lock in share mode
-- 加排它鎖（X)
select * from table_name where ... for update
用 select... in share mode 獲得共享鎖，主要用在需要資料依存關係時來確認某行記錄是否存在，並確保沒有人對這個記錄進行 update 或者 delete 操作。
但是如果當前事務也需要對該記錄進行更新操作,則有可能造成死鎖，對於鎖定行記錄後需要進行更新操作的應用，應該使用 select... for update 方式獲得排他鎖。
三、記錄鎖
1、記錄鎖（Record Locks）
記錄鎖其實很好理解，對錶中的記錄加鎖，叫做記錄鎖，簡稱行鎖。比如
SELECT * FROM `test` WHERE `id`=1 FOR UPDATE;
它會在 id=1 的記錄上加上記錄鎖，以阻止其他事務插入，更新，刪除 id=1 這一行。
需要注意的是：
- d 列必須為唯一索引列或主鍵列，否則上述語句加的鎖就會變成臨鍵鎖(有關臨鍵鎖下面會講)。
- 同時查詢語句必須為精準匹配（=），不能為 >、<、like等，否則也會退化成臨鍵鎖。
其他實現
在通過 主鍵索引 與 唯一索引 對資料行進行 UPDATE 操作時，也會對該行資料加記錄鎖：
-- id 列為主鍵列或唯一索引列
UPDATE SET age = 50 WHERE id = 1;
記錄鎖是鎖住記錄，鎖住索引記錄，而不是真正的資料記錄.
如果要鎖的列沒有索引，進行全表記錄加鎖
記錄鎖也是排它(X)鎖,所以會阻塞其他事務對其插入、更新、刪除。
四、間隙鎖
1、間隙鎖（Gap Locks）
間隙鎖 是 Innodb 在 RR(可重複讀) 隔離級別 下為了解決幻讀問題時引入的鎖機制。間隙鎖是innodb中行鎖的一種。
請務必牢記：使用間隙鎖鎖住的是一個區間，而不僅僅是這個區間中的每一條資料。
舉例來說，假如emp表中只有101條記錄，其empid的值分別是1,2,...,100,101，下面的SQL：
SELECT * FROM emp WHERE empid > 100 FOR UPDATE
當我們用條件檢索資料，並請求共享或排他鎖時，InnoDB不僅會對符合條件的empid值為101的記錄加鎖，也會對empid大於101（這些記錄並不存在）的“間隙”加鎖。
這個時候如果你插入empid等於102的資料的，如果那邊事物還沒有提交，那你就會處於等待狀態，無法插入資料。
有關間隙鎖所需講的東西還是蠻多的，我會單獨寫一篇文章來分析間隙鎖，並在文章中附上完整的示例。
五、臨鍵鎖
1、臨鍵鎖（Next-Key Locks）
Next-key鎖是記錄鎖和間隙鎖的組合，它指的是加在某條記錄以及這條記錄前面間隙上的鎖。
也可以理解為一種特殊的間隙鎖。通過臨建鎖可以解決幻讀的問題。 每個資料行上的非唯一索引列上都會存在一把臨鍵鎖，當某個事務持有該資料行的臨鍵鎖時，會鎖住一段左開右閉區間的資料。需要強調的一點是，
InnoDB 中行級鎖是基於索引實現的。
臨鍵鎖只與 非唯一索引列 有關，在 唯一索引列（包括主鍵列）上不存在臨鍵鎖。
假設有如下表：
id主鍵, age 普通索引
該表中 age 列潛在的臨鍵鎖有：
(-∞, 10],
(10, 24],
(24, 32],
(32, 45],
(45, +∞],
在事務 A 中執行如下命令：
-- 根據非唯一索引列 UPDATE 某條記錄
UPDATE table SET name = Vladimir WHERE age = 24;
-- 或根據非唯一索引列 鎖住某條記錄
SELECT * FROM table WHERE age = 24 FOR UPDATE;
不管執行了上述 SQL 中的哪一句，之後如果在事務 B 中執行以下命令，則該命令會被阻塞：
INSERT INTO table VALUES(100, 26, 'tianqi');
很明顯，事務 A 在對 age 為 24 的列進行 UPDATE 操作的同時，也獲取了 (24, 32] 這個區間內的臨鍵鎖。
總結
這裡對 記錄鎖、間隙鎖、臨鍵鎖 做一個總結
- InnoDB 中的行鎖的實現依賴於索引，一旦某個加鎖操作沒有使用到索引，那麼該鎖就會退化為
表鎖。 - 記錄鎖存在於包括主鍵索引在內的唯一索引中，鎖定單條索引記錄。
- 間隙鎖存在於非唯一索引中，鎖定開區間範圍內的一段間隔，它是基於臨鍵鎖實現的。
- 臨鍵鎖存在於非唯一索引中，該型別的每條記錄的索引上都存在這種鎖，它是一種特殊的間隙鎖，鎖定一段左開右閉的索引區間。
六、意向鎖
1、意向鎖
意向鎖又分為 意向共享鎖（IS）和 意向排他鎖（IX）
- 意向共享(IS)鎖：事務有意向對錶中的某些行加共享鎖（S鎖）
-- 事務要獲取某些行的 S 鎖，必須先獲得表的 IS 鎖。
SELECT column FROM table ... LOCK IN SHARE MODE;
- 意向排他(IX)鎖：事務有意向對錶中的某些行加排他鎖（X鎖）
-- 事務要獲取某些行的 X 鎖，必須先獲得表的 IX 鎖。
SELECT column FROM table ... FOR UPDATE;
首先我們要明白四點
- 意向共享鎖（IS）和 意向排他鎖（IX）都是表鎖。
- 意向鎖是一種 不與行級鎖衝突的表級鎖，這一點非常重要。
- 意向鎖是 InnoDB 自動加的， 不需使用者干預。
- 意向鎖是在 InnoDB 下存在的內部鎖，對於MyISAM 而言 沒有意向鎖之說。
這裡就會有疑惑，既然前面已經有了共享鎖（S鎖）、排它鎖（X鎖）。那麼為什麼需要引入意向鎖呢？它能解決什麼問題呢？
我們可以理解 意向鎖 存在的目的就是 為了讓 InnoDB 中的行鎖和表鎖更高效的共存。
為什麼這麼說，我們來舉一個例子。
舉例
下面有一張表 InnoDB RR隔離級別 id是主鍵
事務 A 獲取了某一行的排他鎖，並未提交：
SELECT * FROM users WHERE id = 6 FOR UPDATE;
事務 B 想要獲取users表的表鎖：
LOCK TABLES users READ;
因為共享鎖與排他鎖互斥，所以事務 B 在檢視對 users 表加共享鎖的時候，必須保證：
- 當前沒有其他事務持有 users 表的排他鎖。
- 當前沒有其他事務持有 users 表中任意一行的排他鎖 。
為了檢測是否滿足第二個條件，事務 B 必須在確保users表不存在任何排他鎖的前提下，去檢測表中的每一行是否存在排他鎖。很明顯這是一個效率很差的做法，但是有了意向鎖之後，情況就不一樣了：事務B只要看錶上有沒有
意向共享鎖，有則說明表中有些行被共享行鎖鎖住了，因此，事務B申請表的寫鎖會被阻塞。這樣是不是就高效多了。
這也解釋就應該清楚，為什麼有意向鎖這個東西存在了。
我們可以舉個生活中的例子，再來理解下為什麼需要存在意向鎖。
打個比方，就像有個遊樂場，很多小朋友進去玩，看門大爺如果要下班鎖遊樂場的門(加表鎖)，他必須確保每個角落都要去檢查一遍，確保每個小朋友都離開了(釋放行鎖)，才可以鎖門。
假設鎖門是件頻繁發生的事情，大爺就會非常崩潰。那大爺想了一個辦法，每個小朋友進入，就把自己的名字寫在本子上，小朋友離開，就把自己的名字劃掉，那大爺就能方便掌握有沒有小朋友在遊樂場裡，不必每個角落都去尋找一遍。
例子中的“小本子”，就是意向鎖，他記錄的資訊並不精細，他只是提醒大爺，有人在屋裡。
這裡我們再來看下 共享(S)鎖、排他(X)鎖、意向共享鎖（IS）、意向排他鎖（IX）的相容性
可以看出 意向鎖之間是互相相容的.那你存在的意義是啥？
意向鎖不會為難意向鎖。也不會為難行級排他(X)/共享(X)鎖,它的存在是為難表級排他(X)/共享(X)鎖。
注意這裡的排他(X)/共享(S)鎖指的都是表鎖！意向鎖不會與行級的共享/排他鎖互斥！ 行級別的X和S按照上面的相容性規則即可。
意向鎖與意向鎖之間永遠是相容的，因為當你不論加行級的X鎖或S鎖，都會自動獲取表級的IX鎖或者IS鎖。也就是你有10個事務，對不同的10行加了行級X鎖，那麼這個時候就存在10個IX鎖。
這10IX存在的目的是啥呢，就是假如這個時候有個事務，想對整個表加排它X鎖,那它不需要遍歷每一行是否存在S或X鎖，而是看有沒有存在意向鎖，只要存在一個意向鎖，那這個事務就加不了表級排它X鎖，要等上面10個IX全部釋放才行。
七、插入意向鎖
1、插入意向鎖
在講解插入意向鎖之前，先來思考一個問題
下面有張表 id主鍵，age普通索引
首先事務 A 插入了一行資料，並且沒有 commit：
INSERT INTO users SELECT 4, 'Bill', 15;
隨後事務 B 試圖插入一行資料：
INSERT INTO users SELECT 5, 'Louis', 16;
請問：
1、事務A使用了什麼鎖？
2、 事務 B 是否會被事務 A 阻塞？
插入意向鎖是在插入一條記錄行前，由 INSERT 操作產生的一種間隙鎖。
該鎖用以表示插入意向，當多個事務在同一區間（gap）插入位置不同的多條資料時，事務之間不需要互相等待。
假設存在兩條值分別為 4 和 7 的記錄，兩個不同的事務分別試圖插入值為 5 和 6 的兩條記錄，每個事務在獲取插入行上獨佔的（排他）鎖前，都會獲取（4，7）之間的間隙鎖，但是因為資料行之間並不衝突，所以兩個事務之間
並不會產生衝突（阻塞等待）。
總結來說，插入意向鎖 的特性可以分成兩部分：
- 插入意向鎖是一種特殊的間隙鎖 —— 間隙鎖可以鎖定開區間內的部分記錄。
- 插入意向鎖之間互不排斥，所以即使多個事務在同一區間插入多條記錄，只要記錄本身（主鍵、唯一索引）不衝突，那麼事務之間就不會出現衝突等待。
需要強調的是，雖然插入意向鎖中含有意向鎖三個字，但是它並不屬於意向鎖而屬於間隙鎖，因為意向鎖是表鎖而插入意向鎖是行鎖。
現在我們可以回答開頭的問題了：
1、 使用插入意向鎖與記錄鎖。
2、事務 A 不會阻塞事務 B。
為什麼不用間隙鎖
如果只是使用普通的間隙鎖會怎麼樣呢？我們在看事務A,其實它一共獲取了3把鎖
- id 為 4 的記錄行的記錄鎖。
- age 區間在（10，15）的間隙鎖。
- age 區間在（15，20）的間隙鎖。
最終，事務 A 插入了該行資料，並鎖住了（10，20）這個區間。
隨後事務 B 試圖插入一行資料：
INSERT INTO users SELECT 5, 'Louis', 16;
因為 16 位於（15，20）區間內，而該區間內又存在一把間隙鎖，所以事務 B 別說想申請自己的間隙鎖了，它甚至不能獲取該行的記錄鎖，自然只能乖乖的等待 事務 A結束，才能執行插入操作。
很明顯，這樣做事務之間將會頻發陷入阻塞等待，插入的併發性非常之差。這時如果我們再去回想我們剛剛講過的插入意向鎖，就不難發現它是如何優雅的解決了併發插入的問題。
總結
- InnoDB在RR的事務隔離級別下，使用插入意向鎖來控制和解決併發插入。
- 插入意向鎖是一種特殊的間隙鎖。
- 插入意向鎖在鎖定區間相同但記錄行本身不衝突的情況下互不排斥。
