【MySQL系列5】深入分析MySQL中鎖並詳解鎖解決幻讀問題

前言

上一篇，我們分析了MySQL中事務以及MVCC相關知識，想要詳細瞭解的請點擊這裏。那麼今天就爲大家介紹一下MySQL中鎖相關的知識。

本文在沒有特別聲明的情況下，均是默認InnoDB引擎，如涉及到其他引擎或者數據庫則會特別指出。

什麼是鎖

鎖是一種用於保證在併發場景下每個事務仍能以一致性的方式讀取和修改數據的方式，當一個事務對某一條數據上鎖之後，其他事務就不能修改或者只能阻塞等待鎖的釋放，所以鎖的粒度大小一定程度上可以影響到訪問數據庫的性能。

從鎖的粒度上來說，我們可以將鎖分爲表鎖和行鎖。

表鎖

顧名思議，表鎖就是直接鎖表，在MyISAM引擎中就只有表鎖。

表鎖的加鎖方式爲：

LOCK TABLE 表名 READ;--鎖定後表只讀
UNLOCK TABLE; --解鎖

行鎖

行鎖，從名字上來看，就是鎖住一行數據，然而，行鎖的實際實現算法會相對複雜，有時候並不僅僅只是鎖住某一條數據，這個後面再展開。

正常的思路是：鎖住一行數據之後，其他事務就不能來訪問這條數據了，那麼我們想象，假如事務A訪問了一條數據，只是拿出來讀一下，並不想去修改，正好事務B也來訪問這條數據，也僅僅只是想拿出來讀一下，並不想去修改，這時候如果因此阻塞了，就有點浪費性能了。所以爲了優化這種讀數據的場景，我們又把行鎖分爲了兩大類型：共享鎖和排他鎖。

共享鎖

共享鎖，Shared Lock，又稱之爲讀鎖，S鎖，就是說一條數據被加了S鎖之後，其他事務也能來讀數據，可以共享一把鎖。
我們可以通過如下語句加共享鎖：

select * from test where id=1 LOCK IN SHARE MODE;

加鎖之後，直到加鎖的事務結束(提交或者回滾)就會釋放鎖。

排他鎖

排他鎖，Exclusive Lock，又稱之爲寫鎖，X鎖。就是說一條數據被加了X鎖之後，其他事務想來訪問這條數據只能阻塞等待鎖的釋放，具有排他性。

當我們在修改數據，如：insert,update,delete的時候MySQL就會自動加上排他鎖，同樣的，我們可以通過如下sql語句手動加上排他鎖：

select * from test where id=1 for update;

在InnoDB引擎中，是允許行鎖和表鎖共存的。

但是這樣就會有一個問題，假如事務A給t表其中一行數據上鎖了，這時候事務B想給t表上一個表鎖，這時候怎麼辦呢？事務B怎麼知道t表有沒有行鎖的存在，如果採用全表遍歷的情況，當表中的數據很大的話，加鎖都要加半天，所以MySQL中就又引入了意向鎖。

意向鎖

意向鎖爲表鎖，分爲兩種類型，分爲：意向共享鎖(Intention Shared Lock)和意向排他鎖(Intention Exclusive Lock)，這兩種鎖又分別可以簡稱爲IS鎖和IX鎖。

意向鎖是MySQL自己維護的，用戶無法手動加意向。

意向鎖有兩大加鎖規則：

• 當需要給一行數據加上S鎖的時候，MySQL會先給這張表加上IS鎖。
• 當需要給一行數據加上X鎖的時候，MySQL會先給這張表加上IX鎖。

這樣的話上面的問題就迎刃而解了，當需要給一張表上表鎖的時候，只需要看這張表是否有對應的意向鎖就可以了，無需遍歷整張表。

各種鎖的兼容關係

下面這張圖是各種鎖的兼容關係，參考自官網：

	X	IX	S	IS
X	互斥	互斥	互斥	互斥
IX	互斥	共享	衝突	共享
S	互斥	互斥	共享	共享
IS	互斥	共享	共享	共享

鎖到底鎖的是什麼

建立以下兩張表，並初始化5條數據，注意test表有2個索引而test2沒有索引：

CREATE TABLE `test` (
  `id` int(11) NOT NULL,
  `name` varchar(50) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `NAME_INDEX` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO test VALUE(1,'張1');
INSERT INTO test VALUE(5,'張5');
INSERT INTO test VALUE(8,'張8');
INSERT INTO test VALUE(10,'張10');
INSERT INTO test VALUE(20,'張20');

CREATE TABLE `test2` (
  `id` varchar(32) NOT NULL,
  `name` varchar(32) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO test2 VALUE(1,'張1');
INSERT INTO test2 VALUE(5,'張5');
INSERT INTO test2 VALUE(8,'張8');
INSERT INTO test2 VALUE(10,'張10');
INSERT INTO test2 VALUE(20,'張20');

舉例猜測

在行鎖中，假如我們對一行記錄加鎖，那麼到底是把什麼東西鎖住了，我們來看下面兩個例子：
舉例1（操作test表）：

事務A	事務B
BEGIN;
SELECT * FROM test WHERE id=1 FOR UPDATE;
	SELECT * FROM test WHERE id=1 FOR UPDATE; 阻塞
	SELECT * FROM test WHERE id=5 FOR UPDATE; 加鎖成功
COMMIT;（釋放鎖）
	SELECT * FROM test WHERE id=1 FOR UPDATE; 加鎖成功

舉例2（操作test2表）：

事務A	事務B
BEGIN;
SELECT * FROM test2 WHERE id=1 FOR UPDATE;
	SELECT * FROM test2 WHERE id=1 FOR UPDATE; 阻塞
	SELECT * FROM test2 WHERE id=5 FOR UPDATE; 阻塞
COMMIT;（釋放鎖）
	SELECT * FROM test2 WHERE id=1 FOR UPDATE; 加鎖成功

從上面兩個例子我們可以發現，test表好像確實是鎖住了id=1這一行的記錄，而test2表好像不僅僅是鎖住了id=1這一行記錄，實際上經過嘗試我們就知道，test2表是被鎖表了，所以其實MySQL中InnoDB鎖住的是索引，當沒有索引的時候就會鎖表。

接下來再看一個場景：

事務A	事務B
BEGIN;
SELECT * FROM test WHERE name=‘張1’ FOR UPDATE;
	SELECT name FROM test WHERE name=‘張1’ FOR UPDATE; 阻塞
	SELECT id FROM test WHERE id=1 FOR UPDATE; 阻塞
COMMIT;（釋放鎖）
	SELECT id FROM test WHERE id=1 FOR UPDATE; 加鎖成功

這個例子中我們是把name索引鎖住了，然後我們在事務B中通過主鍵索引只查id，這樣就用到name索引了，但是最後發現也被阻塞了。所以我們又可以得出下面的結論，MySQL索引不但鎖住了輔助索引，還會把輔助索引對應的主鍵索引一起鎖住。

到這裏，可能有人會有懷疑，那就是我把輔助索引鎖住了，但是假如加鎖的時候，只用到了覆蓋索引（關於覆蓋索引的相關知識，想要詳細瞭解的，可以點擊這裏），然後我再去查主鍵會怎麼樣呢？

接下來讓我們再驗證一下：

事務A	事務B
BEGIN;
SELECT name FROM test WHERE name=‘張1’ FOR UPDATE;
	SELECT name FROM test WHERE name=‘張1’ FOR UPDATE; 阻塞
	SELECT * FROM test WHERE id=1 FOR UPDATE; 阻塞
	SELECT id FROM test WHERE id=1 FOR UPDATE; 阻塞
COMMIT;（釋放鎖）
	SELECT id FROM test WHERE id=1 FOR UPDATE; 加鎖成功

我們可以看到，就算只是用到了輔助索引加鎖，MySQL還是會把主鍵索引鎖住，而主鍵索引的B+樹葉子節點中，又存儲了整條數據，所以查詢任何字段都會被鎖定。

到這裏，我們可以明確的給鎖到底鎖住了什麼下結論了：

結論

InnoDB引擎中，鎖鎖的是索引：

• 假如一張表沒有索引，MySQL會進行鎖表(其實鎖住的是隱藏列ROWID的主鍵索引)
• 假如我們對輔助索引加鎖，那麼輔助索引所對應的主鍵索引也會被鎖住
• 主鍵索引被鎖住，實際上就等於是整條記錄都被鎖住了(主鍵索引葉子節點存儲了整條數據)

行鎖的算法

上一篇介紹事務的時候我們提到了，MySQL通過加鎖來防止了幻讀，但是如果行鎖只是鎖住一行記錄，好像並不能防止幻讀，所以行鎖鎖住一條記錄的話只是其中一種情況，實際上行鎖有三種算法：記錄鎖(Record Lock)，間隙鎖(Gap Lock)和臨鍵鎖(Next-Key Lock)，而之所以能做到防止幻讀，正是臨鍵鎖起的作用。

記錄鎖(Record Lock)

記錄鎖就是上面介紹的，當我們的查詢能命中一條記錄的時候，InnoDB就會使用記錄鎖，鎖住所命中的這一行記錄。

間隙鎖(Gap Lock)

當我們的查詢沒有命中記錄的時候，這時候InnoDB就會加上一個間隙鎖。

事務A	事務B
BEGIN;
SELECT * FROM test WHERE id=1 FOR UPDATE;
	INSERT INTO test VALUE (2,‘張2’); 阻塞
	INSERT INTO test VALUE (3,‘張3’); 阻塞
	SELECT * FROM test WHERE id=2 FOR UPDATE; 加鎖成功
COMMIT;（釋放鎖）

從上面的例子中，我們可以得出結論：

• 間隙鎖與間隙鎖之間不衝突，也就是事務A加了間隙鎖，事務B可以在同一個間隙中加間隙鎖。(之所以會用到間隙鎖就是沒有命中數據的時候，所以並沒有必要去阻塞讀，也沒有必要阻塞其他事務對同一個間隙加鎖)
• 間隙鎖主要是會阻塞插入操作

間隙是如何確定的

test表中有5條記錄，主鍵值分別爲:1,5,8,10,20。那麼就會有如下六個間隙：
(-∞,1),(1,5),(5,8),(8,10),(10,20),(20,+∞)

而假如主鍵不是int類型，那麼就會轉化爲ASCII碼之後再確定間隙。

臨鍵鎖(Next-Key Lock)

臨鍵鎖就是記錄鎖和間隙鎖的結合。當我們進行一個範圍查詢，不但命中了一條或者多條記錄，且同時包括了間隙，這時候就會使用臨鍵鎖，臨鍵鎖是InnoDB中行鎖的默認算法。

注意了，這裏僅針對RR隔離級別，對於RC隔離級除了外鍵約束和唯一性約束會加間隙鎖，沒有間隙鎖，自然也就沒有了臨鍵鎖，所以RC級別下加的行鎖都是記錄鎖，沒有命中記錄則不加鎖，所以RC級別是沒有解決幻讀問題的。

臨鍵鎖在以下兩個條件時會降級成爲間隙鎖或者記錄鎖：

• 當查詢未命中任務記錄時，會降級爲間隙鎖。
• 當使用主鍵或者唯一索引命中了一條記錄時，會降級爲記錄鎖。

事務A	事務B
BEGIN;
SELECT * FROM test WHERE id>=2 AND id<=6 FOR UPDATE;
	INSERT INTO test VALUE (2,‘張2’); 阻塞
	INSERT INTO test VALUE (6,‘張6’); 阻塞
	INSERT INTO test VALUE (8,‘張8’); 阻塞
	SELECT * FROM test WHERE id=8 FOR UPDATE; 阻塞
	INSERT INTO test VALUE (9,‘張9’); 插入成功
COMMIT;（釋放鎖）

上面這個例子，事務A加的鎖跨越了(1,5)和(5,8)兩個間隙，且同時命中了5，然後我們發現我們對id=8這條數據進行操作也阻塞了，但是9這條記錄插入成功了。

臨鍵鎖加鎖規則

臨鍵鎖的劃分是按照左開右閉的區間來劃分的，也就是我們可以把test表中的記錄劃分出如下區間：(-∞,1],(1,5],(5,8],(8,10],(10,20],(20,+∞)。

那麼臨鍵鎖到底鎖住了哪些範圍呢？
臨鍵鎖中鎖住的是最後一個命中記錄的 key 和其下一個左開右閉的區間
那麼上面的例子中其實鎖住了(1,5]和(5,8]這兩個區間。

臨鍵鎖爲何能解決幻讀問題

臨鍵鎖爲什麼要鎖住命中記錄的下一個左開右閉的區間？答案就是爲了解決幻讀。

我們想一想上面的查詢範圍id>=2且id<=6，如果我們事務A只鎖住了(1,5]這個區間，假如這時候事務B插入一條數據id=6，那麼事務A再去查詢，就會多出來了一條記錄id=6，就會出現了幻讀，所以我把你下一個區間5,10]也給鎖住，就可以避免了幻讀。

當然，其實如果我們執行的查詢剛好是id>=2且id<=5，那麼就算只鎖住了(1,5]，同樣能避免幻讀問題，只是我們要考慮到查詢範圍的最大值沒有命中記錄的情況，而鎖住了下一個區間，可以確保不論是哪種範圍查詢，都可以避免幻讀的產生。

在我們使用鎖的時候，有一個問題是需要注意和避免的，我們知道，排它鎖有互斥的特性。一個事務持有鎖的時候，會阻止其他的事務獲取鎖，這個時候會造成阻塞等待，那麼假如事務一直等待下去，就會一直佔用CPU資源，所以，鎖等待會有一個超時時間，在InnoDB引擎中，可以通過參數：innodb_lock_wait_timeout查詢：

SHOW VARIABLES LIKE 'innodb_lock_wait_timeout';

默認超時時間是50s，超時後會自動釋放鎖回滾事務。但是我們想一下，假如事務A在等待事務B釋放鎖，而事務B又在等待事務A釋放鎖，這時候就會產生一個等待環路了，而這種情況是無論等待多久都不可能會獲取鎖成功的，所以是沒有必要去等50s的，這種形成等待環路的現象又叫做死鎖。

死鎖(Dead Lock)

什麼是死鎖

死鎖是指的兩個或者兩個以上的事務在執行過程中，因爲爭奪鎖資源而造成的一種互相等待的現象。

事務A	事務B
BEGIN;
SELECT * FROM test WHERE id=10 FOR UPDATE;
	BEGIN;
	SELECT * FROM test WHERE id=20 FOR UPDATE;
SELECT * FROM test WHERE id=20 FOR UPDATE;
	SELECT * FROM test WHERE id=10 FOR UPDATE;
	ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
查詢出結果

我們可以看到，發生死鎖之後就會立刻回滾，而不會漫無目的的去等待50s之後超時再回滾事務，那麼MySQL是如何知道產生了死鎖的，是如何檢測死鎖的發生呢？

死鎖的檢測

目前數據庫大部分採用wait-for graph（等待圖）的方式來進行死鎖檢測，InnoDB引擎也是採用這種方式來檢測死鎖。數據庫中會記錄兩種信息：

• 鎖的信息鏈表
• 事務的等待鏈表
  wait-for graph 算法會根據這兩個信息構建一張圖，當圖中存在迴路，則證明存在死鎖：
  如下圖中，t1和t2之間存在迴路，這就證明t1和t2事務之間存在死鎖
  

死鎖的避免

• 儘量將長事務拆分成多個小事務
• 查詢時避免沒有where條件語句查詢，並儘可能使用索引查詢
• 可以的話儘量使用等值查詢

鎖信息查詢

InnoDB在information_schema庫下提供了3張表供我們查詢並排查事務和鎖相關問題。

INNODB_TRX

記錄了當前在InnoDB中執行的每個事務的信息，包括事務是否在等待鎖、事務何時啓動以及事務正在執行的SQL語句(如果有的話)。

列名	含義
trx_id	InnoDD引擎中的事務的唯一ID
trx_state	事務狀態:RUNNING, LOCK WAIT, ROLLING BACK,COMMITTING
trx_started	事務的開始時間
trx_requested_lock_id	等待會務的鎖ID,如果trx_state不爲LOCK WAIT時，爲null
trx_wait_started	事務等待開始的時間
trx_weight	事務的權重，反映了一個事務修改和鎖住的行數，當發生死鎖時候，InnoDB會選擇該值最小的事務進行回滾
trx_mysql_thread_id	MySQL中的線程ID，可以通過SHOW PROCESSLIST查詢
trx_query	事務運行的sql語句
trx_operation_state	事務的當前操作狀態，如果沒有則爲NULL
trx_tables_in_use	當前事務中執行的sql語句用到的表數量
trx_tables_locked	已經被鎖定表的數量(因爲用的是行鎖，所以雖然顯示一張表被鎖了，但是可能只是鎖定的其中一行或幾行，所以其他行還是可以被其他事務訪問)
trx_lock_structs	當前事務保留的鎖數量
trx_lock_memory_bytes	當前事務的索結構在內存中的大小
trx_rows_locked	當前事務中鎖住的大致行數，包括已經被打上刪除標記等物理存在的但是對當前事務不可見的數據
trx_rows_modified	當前事務修改或者插入的行數
trx_concurrency_tickets	併發數，指的是當前事務未結束前仍然可以執行的併發數,可以通過系統變量innodb_concurrency_tickets設置
trx_isolation_level	當前事務隔離級別
trx_unique_checks	是否爲當前事務打開或者關閉唯一約束:0-否1-是
trx_foreign_key_checks	是否爲當前事務打開或者關閉外鍵約束:0-否1-是
trx_last_foreign_key_error	最後一個外鍵錯誤信息，沒有則爲空
trx_adaptive_hash_latched	自適應哈希索引是否被當前事務鎖定。在分區自適應哈希索引搜索系統時，單個事務不會鎖定整個自適應哈希索引。自適應哈希索引分區由innodb_adaptive_hash_index_parts控制，默認設置爲8。
trx_adaptive_hash_timeout	是立即放棄自適應哈希索引的搜索latch，還是在來自MySQL的調用中保留它。當沒有自適應哈希索引爭用時，這個值將保持爲零，並且語句會保留latch直到它們完成。在爭用期間，它的計數減少到零，並且語句在每一行查找之後立即釋放鎖存。當自適應哈希索引搜索系統被分區時(由innodb_adaptive_hash_index_parts控制)，該值保持爲0。
trx_is_read_only	當前事務是否只讀:0-否1-是
trx_autocommit_non_locking	值爲1表示這是一條不包含for update和lock in share model的語句，而且是在開啓autocommit情況下執行的有且僅有這一條語句，當這列和TRX_IS_READ_ONLY都爲1時，InnoDB會優化事務以減少與更改表數據事務的相關開銷。

INNODB_LOCKS

記錄了事務請求鎖但未獲得的每個鎖的信息和一個事務持有鎖但正在阻塞另一個事務的每個鎖的信息。

列名	含義
lock_id	鎖的id(雖然LOCK_ID當前包含TRX_ID，但LOCK_ID中的數據格式隨時可能更改，不要編寫解析LOCK_ID值的應用程序)
lock_trx_id	上一張表的事務ID
lock_mode	鎖的模式: S, X, IS, IX, GAP, AUTO_INC,UNKNOWN
lock_type	鎖的類型是表鎖還是行鎖
lock_table	被鎖住的表
lock_index	被鎖住的索引，表鎖則爲NULL
lock_space	鎖記錄的空間id，表鎖則爲NULL
lock_page	事務鎖定頁的數量，表鎖則爲NULL
lock_rec	事務鎖定行的數量，表鎖則爲NULL
lock_data	事務鎖定的主鍵值，表鎖則爲NULL

INNODB_LOCK_WAITS

記錄了鎖等待的信息。每個被阻塞的InnoDB事務包含一個或多個行，表示它所請求的鎖以及正在阻塞該請求的任何鎖。

列名	含義
lock_id	鎖的id(雖然LOCK_ID當前包含TRX_ID，但LOCK_ID中的數據格式隨時可能更改，不要編寫解析LOCK_ID值的應用程序)
requesting_trx_id	申請鎖資源的事務ID
requested_lock_id	申請的鎖的ID
blocking_trx_id	阻塞的事務ID
blocking_lock_id	阻塞的鎖的ID