疫情期間在家工作時，同事使用了 insert into on duplicate key update 語句進行插入去重，但是在測試過程中發現了死鎖現象: ``` ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction ``` 由於開發任務緊急，只是暫時規避了一下，但是對觸發死鎖的原因和相關原理不甚瞭解，於是這幾天一直在查閱相關資料，總結出一個系列文章供大家參考。本篇是上篇，主要介紹 MySQL 加鎖原理和鎖的不同模式或型別的基本知識。後續會講解常見語句的加鎖情況和通過 MySQL 死鎖日誌分析死鎖原因。 由於本篇文章涉及很多 MySQL 的基礎知識，大家可以自行閱讀我之前的 MySQL系列文章 [《MySQL探祕》](http://remcarpediem.net/categories/MySQL/)中的對應章節。 ### 表鎖和行鎖 我們首先來了解一下表鎖和行鎖：表鎖是指對一整張表加鎖，一般是 DDL 處理時使用；而行鎖則是鎖定某一行或者某幾行，或者行與行之間的間隙。 表鎖由 MySQL Server 實現，行鎖則是儲存引擎實現，不同的引擎實現的不同。在 MySQL 的常用引擎中 InnoDB 支援行鎖，而 MyISAM 則只能使用 MySQL Server 提供的表鎖。  ### 表鎖 表鎖由 MySQL Server 實現，一般在執行 DDL 語句時會對整個表進行加鎖，比如說 ALTER TABLE 等操作。在執行 SQL 語句時，也可以明確指定對某個表進行加鎖。 ``` mysql> lock table user read(write); # 分為讀鎖和寫鎖 Query OK, 0 rows affected (0.00 sec) mysql> select * from user where id = 100; # 成功 mysql> select * from role where id = 100; # 失敗，未提前獲取該 role的讀表鎖 mysql> update user set name = 'Tom' where id = 100; # 失敗，未提前獲得user的寫表鎖 mysql> unlock tables; # 顯示釋放表鎖 Query OK, 0 rows affected (0.00 sec) ``` 表鎖使用的是一次性鎖技術，也就是說，在會話開始的地方使用 lock 命令將後續需要用到的表都加上鎖，在表釋放前，只能訪問這些加鎖的表，不能訪問其他表，直到最後通過 unlock tables 釋放所有表鎖。 除了使用 unlock tables 顯示釋放鎖之外，會話持有其他表鎖時執行lock table 語句會釋放會話之前持有的鎖；會話持有其他表鎖時執行 start transaction 或者 begin 開啟事務時，也會釋放之前持有的鎖。 ### 行鎖 不同儲存引擎的行鎖實現不同，後續沒有特別說明，則行鎖特指 InnoDB 實現的行鎖。 在瞭解 InnoDB 的加鎖原理前，需要對其儲存結構有一定的瞭解。InnoDB 是聚簇索引，也就是 B+樹的葉節點既儲存了主鍵索引也儲存了資料行。而 InnoDB 的二級索引的葉節點儲存的則是主鍵值，所以通過二級索引查詢資料時，還需要拿對應的主鍵去聚簇索引中再次進行查詢。關於 InnoDB 和 MyISAM 的索引的詳細知識可以閱讀《Mysql探索(一):B+Tree索引》一文。  下面以兩條 SQL 的執行為例，講解一下 InnoDB 對於單行資料的加鎖原理。 ``` update user set age = 10 where id = 49; update user set age = 10 where name = 'Tom'; ``` 第一條 SQL 使用主鍵索引來查詢，則只需要在 id = 49 這個主鍵索引上加上寫鎖；第二條 SQL 則使用二級索引來查詢，則首先在 name = Tom 這個索引上加寫鎖，然後由於使用 InnoDB 二級索引還需再次根據主鍵索引查詢，所以還需要在 id = 49 這個主鍵索引上加寫鎖，如上圖所示。 也就是說使用主鍵索引需要加一把鎖，使用二級索引需要在二級索引和主鍵索引上各加一把鎖。 根據索引對單行資料進行更新的加鎖原理了解了，那如果更新操作涉及多個行呢，比如下面 SQL 的執行場景。 ``` update user set age = 10 where id > 49; ``` 上述 SQL 的執行過程如下圖所示。MySQL Server 會根據 WHERE 條件讀取第一條滿足條件的記錄，然後 InnoDB 引擎會將第一條記錄返回並加鎖，接著 MySQL Server 發起更新改行記錄的 UPDATE 請求，更新這條記錄。一條記錄操作完成，再讀取下一條記錄，直至沒有匹配的記錄為止。  這種場景下的鎖的釋放較為複雜，有多種的優化方式，我對這塊暫時還沒有了解，還請知道的小夥伴在下方留言解釋。 下面主要依次介紹 InnoDB 中鎖的模式和型別，鎖的型別是指鎖的粒度或者鎖具體加在什麼地方；而鎖模式描述的是鎖的相容性，也就是加的是什麼鎖，比如寫鎖或者讀鎖。 內容基本來自於 MySQL 的技術文件 innodb-lock 一章，感興趣的同學可以直接去閱讀原文，原文地址為見文章末尾。 ### 行鎖的模式 鎖的模式有：讀意向鎖，寫意向鎖，讀鎖，寫鎖和自增鎖(auto_inc)，下面我們依次來看。 #### 讀寫鎖 讀鎖，又稱共享鎖（Share locks，簡稱 S 鎖），加了讀鎖的記錄，所有的事務都可以讀取，但是不能修改，並且可同時有多個事務對記錄加讀鎖。 寫鎖，又稱排他鎖（Exclusive locks，簡稱 X 鎖），或獨佔鎖，對記錄加了排他鎖之後，只有擁有該鎖的事務可以讀取和修改，其他事務都不可以讀取和修改，並且同一時間只能有一個事務加寫鎖。 ### 讀寫意向鎖 由於表鎖和行鎖雖然鎖定範圍不同，但是會相互衝突。所以當你要加表鎖時，勢必要先遍歷該表的所有記錄，判斷是否加有排他鎖。這種遍歷檢查的方式顯然是一種低效的方式，MySQL 引入了意向鎖，來檢測表鎖和行鎖的衝突。 意向鎖也是表級鎖，也可分為讀意向鎖（IS 鎖）和寫意向鎖（IX 鎖）。當事務要在記錄上加上讀鎖或寫鎖時，要首先在表上加上意向鎖。這樣判斷表中是否有記錄加鎖就很簡單了，只要看下錶上是否有意向鎖就行了。 意向鎖之間是不會產生衝突的，也不和 AUTO_INC 表鎖衝突，它只會阻塞表級讀鎖或表級寫鎖，另外，意向鎖也不會和行鎖衝突，行鎖只會和行鎖衝突。 ### 自增鎖 AUTO_INC 鎖又叫自增鎖（一般簡寫成 AI 鎖），是一種表鎖，當表中有自增列（AUTO_INCREMENT）時出現。當插入表中有自增列時，資料庫需要自動生成自增值，它會先為該表加 AUTO_INC 表鎖，阻塞其他事務的插入操作，這樣保證生成的自增值肯定是唯一的。AUTO_INC 鎖具有如下特點： - AUTO_INC 鎖互不相容，也就是說同一張表同時只允許有一個自增鎖； - 自增值一旦分配了就會 +1，如果事務回滾，自增值也不會減回去，所以自增值可能會出現中斷的情況。 顯然，AUTO_INC 表鎖會導致併發插入的效率降低，為了提高插入的併發性，MySQL 從 5.1.22 版本開始，引入了一種可選的輕量級鎖（mutex）機制來代替 AUTO_INC 鎖，可以通過引數 innodb_autoinc_lock_mode 來靈活控制分配自增值時的併發策略。具體可以參考 MySQL 的 AUTO_INCREMENT Handling in InnoDB 一文，連結在文末。 #### 不同模式鎖的相容矩陣 下面是各個表鎖之間的相容矩陣。  總結起來有下面幾點： - 意向鎖之間互不衝突； - S 鎖只和 S/IS 鎖相容，和其他鎖都衝突； - X 鎖和其他所有鎖都衝突； - AI 鎖只和意向鎖相容； ### 行鎖的型別 根據鎖的粒度可以把鎖細分為表鎖和行鎖，行鎖根據場景的不同又可以進一步細分，依次為 Next-Key Lock，Gap Lock 間隙鎖，Record Lock 記錄鎖和插入意向 GAP 鎖。 不同的鎖鎖定的位置是不同的，比如說記錄鎖只鎖住對應的記錄，而間隙鎖鎖住記錄和記錄之間的間隔，Next-Key Lock 則所屬記錄和記錄之前的間隙。不同型別鎖的鎖定範圍大致如下圖所示。  下面我們來依次瞭解一下不同的型別的鎖。 ### 記錄鎖 記錄鎖是最簡單的行鎖，並沒有什麼好說的。上邊描述 InnoDB 加鎖原理中的鎖就是記錄鎖，只鎖住 id = 49 或者 name = 'Tom' 這一條記錄。 當 SQL 語句無法使用索引時，會進行全表掃描，這個時候 MySQL 會給整張表的所有資料行加記錄鎖，再由 MySQL Server 層進行過濾。但是，在 MySQL Server 層進行過濾的時候，如果發現不滿足 WHERE 條件，會釋放對應記錄的鎖。這樣做，保證了最後只會持有滿足條件記錄上的鎖，但是每條記錄的加鎖操作還是不能省略的。 所以更新操作必須要根據索引進行操作，沒有索引時，不僅會消耗大量的鎖資源，增加資料庫的開銷，還會極大的降低了資料庫的併發效能。 ### 間隙鎖 還是最開始更新使用者年齡的例子，如果 id = 49 這條記錄不存在，這個 SQL 語句還會加鎖嗎？答案是可能有，這取決於資料庫的隔離級別。這種情況下，在 RC 隔離級別不會加任何鎖，在 RR 隔離級別會在 id = 49 前後兩個索引之間加上間隙鎖。 間隙鎖是一種加在兩個索引之間的鎖，或者加在第一個索引之前，或最後一個索引之後的間隙。這個間隙可以跨一個索引記錄，多個索引記錄，甚至是空的。使用間隙鎖可以防止其他事務在這個範圍內插入或修改記錄，保證兩次讀取這個範圍內的記錄不會變，從而不會出現幻讀現象。 值得注意的是，間隙鎖和間隙鎖之間是互不衝突的，間隙鎖唯一的作用就是為了防止其他事務的插入，所以加間隙 S 鎖和加間隙 X 鎖沒有任何區別。 ### Next-Key 鎖 Next-key鎖是記錄鎖和間隙鎖的組合，它指的是加在某條記錄以及這條記錄前面間隙上的鎖。假設一個索引包含 15、18、20 ，30，49，50 這幾個值，可能的 Next-key 鎖如下： ``` (-∞, 15]，(15, 18]，(18, 20]，(20, 30]，(30, 49]，(49, 50]，(50, +∞) ``` 通常我們都用這種左開右閉區間來表示 Next-key 鎖，其中，圓括號表示不包含該記錄，方括號表示包含該記錄。前面四個都是 Next-key 鎖，最後一個為間隙鎖。 和間隙鎖一樣，在 RC 隔離級別下沒有 Next-key 鎖，只有 RR 隔離級別才有。還是之前的例子，如果 id 不是主鍵，而是二級索引，且不是唯一索引，那麼這個 SQL 在 RR 隔離級別下就會加如下的 Next-key 鎖 (30, 49](49, 50) 此時如果插入一條 id = 31 的記錄將會阻塞住。之所以要把 id = 49 前後的間隙都鎖住，仍然是為了解決幻讀問題，因為 id 是非唯一索引，所以 id = 49 可能會有多條記錄，為了防止再插入一條 id = 49 的記錄。 ### 插入意向鎖 插入意向鎖是一種特殊的間隙鎖（簡寫成 II GAP）表示插入的意向，只有在 INSERT 的時候才會有這個鎖。注意，這個鎖雖然也叫意向鎖，但是和上面介紹的表級意向鎖是兩個完全不同的概念，不要搞混了。 插入意向鎖和插入意向鎖之間互不衝突，所以可以在同一個間隙中有多個事務同時插入不同索引的記錄。譬如在上面的例子中，id = 30 和 id = 49 之間如果有兩個事務要同時分別插入 id = 32 和 id = 33 是沒問題的，雖然兩個事務都會在 id = 30 和 id = 50 之間加上插入意向鎖，但是不會衝突。 插入意向鎖只會和間隙鎖或 Next-key 鎖衝突，正如上面所說，間隙鎖唯一的作用就是防止其他事務插入記錄造成幻讀，正是由於在執行 INSERT 語句時需要加插入意向鎖，而插入意向鎖和間隙鎖衝突，從而阻止了插入操作的執行。 #### 不同型別鎖的相容矩陣 不同型別鎖的相容下如下圖所示。  其中，第一行表示已有的鎖，第一列表示要加的鎖。插入意向鎖較為特殊，所以我們先對插入意向鎖做個總結，如下： - 插入意向鎖不影響其他事務加其他任何鎖。也就是說，一個事務已經獲取了插入意向鎖，對其他事務是沒有任何影響的； - 插入意向鎖與間隙鎖和 Next-key 鎖衝突。也就是說，一個事務想要獲取插入意向鎖，如果有其他事務已經加了間隙鎖或 Next-key 鎖，則會阻塞。 其他型別的鎖的規則較為簡單： - 間隙鎖不和其他鎖（不包括插入意向鎖）衝突； - 記錄鎖和記錄鎖衝突，Next-key 鎖和 Next-key 鎖衝突，記錄鎖和 Next-key 鎖衝突； ### 後記 下一篇文章我們來看一下具體 SQL 的加鎖分析和死鎖日誌分析，請小夥伴多多留意和關注，有問題的可以文章下方留言。 [個人部落格，歡迎來玩](http://remcarpediem.net/)  ### 參考 - https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html#innodb-record-locks - https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html#innodb-record-locks - https://www.aneasystone.com/archives/2017/11/solving-dead-locks-t