疫情期間在家工作時，同事使用了 insert into on duplicate key update 語句進行插入去重，但是在測試過程中發生了死鎖現象:
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
由於開發任務緊急，只是暫時規避了一下，但是對觸發死鎖的原因和相關原理不甚瞭解，於是這幾天一直在查閱相關資料，總結出一個系列文章供大家參考，本篇是上篇，主要介紹 MySQL 加鎖原理和鎖的不同模式或類型的基本知識。後續會講解常見語句的加鎖情況和通過 MySQL 死鎖日誌分析死鎖原因。
由於本篇文章涉及很多 MySQL 的基礎知識，大家可以自行閱讀我之前的 MySQL系列文章 《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 表鎖衝突，它只會阻塞表級讀鎖或表級寫鎖，另外，意向鎖也不會和行鎖衝突，行鎖只會和行鎖衝突。
自增鎖
AUTOINC 鎖又叫自增鎖（一般簡寫成 AI 鎖），是一種表鎖，當表中有自增列（AUTOINCREMENT）時出現。當插入表中有自增列時，數據庫需要自動生成自增值，它會先爲該表加 AUTOINC 表鎖，阻塞其他事務的插入操作，這樣保證生成的自增值肯定是唯一的。AUTOINC 鎖具有如下特點：
- AUTO_INC 鎖互不兼容，也就是說同一張表同時只允許有一個自增鎖；
- 自增值一旦分配了就會 +1，如果事務回滾，自增值也不會減回去，所以自增值可能會出現中斷的情況。
顯然，AUTOINC 表鎖會導致併發插入的效率降低，爲了提高插入的併發性，MySQL 從 5.1.22 版本開始，引入了一種可選的輕量級鎖（mutex）機制來代替 AUTOINC 鎖，可以通過參數 innodbautoinclockmode 來靈活控制分配自增值時的併發策略。具體可以參考 MySQL 的 AUTOINCREMENT 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 語句的加鎖場景。瞭解了這幾種場景，相信小夥伴們也能舉一反三，靈活地分析真實開發過程中遇到的加鎖問題。
如下圖所示，數據庫的隔離等級，SQL 語句和當前數據庫數據會共同影響該條 SQL 執行時數據庫生成的鎖模式，鎖類型和鎖數量。
下面，我們會首先講解一下隔離等級、不同 SQL 語句 和 當前數據庫數據對生成鎖影響的基本規則，然後再依次具體 SQL 的加鎖場景。
隔離等級對加鎖的影響
MySQL 的隔離等級對加鎖有影響，所以在分析具體加鎖場景時，首先要確定當前的隔離等級。
- 讀未提交（Read Uncommitted 後續簡稱 RU）：可以讀到未提交的讀，基本上不會使用該隔離等級，所以暫時忽略。
- 讀已提交（Read Committed 後續簡稱 RC）：存在幻讀問題，對當前讀獲取的數據加記錄鎖。
- 可重複讀（Repeatable Read 後續簡稱 RR）：不存在幻讀問題，對當前讀獲取的數據加記錄鎖，同時對涉及的範圍加間隙鎖，防止新的數據插入，導致幻讀。
- 序列化（Serializable）：從 MVCC 併發控制退化到基於鎖的併發控制，不存在快照讀，都是當前讀，併發效率急劇下降，不建議使用。
這裏說明一下，RC 總是讀取記錄的最新版本，而 RR 是讀取該記錄事務開始時的那個版本，雖然這兩種讀取的版本不同，但是都是快照數據，並不會被寫操作阻塞，所以這種讀操作稱爲 快照讀（Snapshot Read）
MySQL 還提供了另一種讀取方式叫當前讀（Current Read），它讀的不再是數據的快照版本，而是數據的最新版本，並會對數據加鎖，根據語句和加鎖的不同，又分成三種情況：
- SELECT ... LOCK IN SHARE MODE：加共享(S)鎖
- SELECT ... FOR UPDATE：加排他(X)鎖
- INSERT / UPDATE / DELETE：加排他(X)鎖
當前讀在 RR 和 RC 兩種隔離級別下的實現也是不一樣的：RC 只加記錄鎖，RR 除了加記錄鎖，還會加間隙鎖，用於解決幻讀問題。
不同 SQL 語句對加鎖的影響
不同的 SQL 語句當然會加不同的鎖，總結起來主要分爲五種情況：
- SELECT ... 語句正常情況下爲快照讀，不加鎖；
- SELECT ... LOCK IN SHARE MODE 語句爲當前讀，加 S 鎖；
- SELECT ... FOR UPDATE 語句爲當前讀，加 X 鎖；
- 常見的 DML 語句（如 INSERT、DELETE、UPDATE）爲當前讀，加 X 鎖；
- 常見的 DDL 語句（如 ALTER、CREATE 等）加表級鎖，且這些語句爲隱式提交，不能回滾。
其中，當前讀的 SQL 語句的 where 從句的不同也會影響加鎖，包括是否使用索引，索引是否是唯一索引等等。
當前數據對加鎖的影響
SQL 語句執行時數據庫中的數據也會對加鎖產生影響。
比如一條最簡單的根據主鍵進行更新的 SQL 語句，如果主鍵存在，則只需要對其加記錄鎖，如果不存在，則需要在加間隙鎖。
至於其他非唯一性索引更新或者插入時的加鎖也都不同程度的受到現存數據的影響，後續我們會一一說明。
具體場景分析
具體 SQL 場景分析主要借鑑何登成前輩的《MySQL 加鎖處理分析》文章和 aneasystone 的系列文章，在他們的基礎上進行了總結和整理。
我們使用下面這張 book 表作爲實例，其中 id 爲主鍵，ISBN（書號）爲二級唯一索引，Author（作者）爲二級非唯一索引，score（評分）無索引。
UPDATE 語句加鎖分析
下面，我們先來分析 UPDATE 相關 SQL 在使用較爲簡單 where 從句情況下加鎖情況。其中的分析原則也適用於 UPDATE,DELETE 和 SELECT ... FOR UPDATE等當前讀的語句。
聚簇索引，查詢命中
聚簇索引就是 InnoDB 存儲引擎下的主鍵索引，具體可參考《MySQL索引》。
下圖展示了使用 UPDATE book SET score = 9.2 WHERE ID = 10 語句命中的情況下在 RC 和 RR 隔離等級下的加鎖，兩種隔離等級下沒有任何區別，都是對 ID = 10 這個索引加排他記錄鎖。
聚簇索引，查詢未命中
下圖展示了 UPDATE book SET score = 9.2 WHERE ID = 16 語句未命中時 RR 隔離級別下的加鎖情況。
在 RC 隔離等級下，不需要加鎖；而在 RR 隔離級別會在 ID = 16 前後兩個索引之間加上間隙鎖。
值得注意的是，間隙鎖和間隙鎖之間是互不衝突的，間隙鎖唯一的作用就是爲了防止其他事務的插入新行，導致幻讀，所以加間隙 S 鎖和加間隙 X 鎖沒有任何區別。
二級唯一索引，查詢命中
下圖展示了 UPDATE book SET score = 9.2 WHERE ISBN = 'N0003' 在 RC 和 RR 隔離等級下命中時的加鎖情況。
在 InnoDB 存儲引擎中，二級索引的葉子節點保存着主鍵索引的值，然後再拿主鍵索引去獲取真正的數據行，所以在這種情況下，二級索引和主鍵索引都會加排他記錄鎖。
二級唯一索引，查詢未命中
下圖展示了 UPDATE book SET score = 9.2 WHERE ISBN = 'N0008' 語句在 RR 隔離等級下未命中時的加鎖情況，RC 隔離等級下該語句未命中不會加鎖。
因爲 N0008 大於 N0007，所以要鎖住 (N0007,正無窮)這段區間，而 InnoDB 的索引一般都使用 Suprenum Record 和 Infimum Record 來分別表示記錄的上下邊界。Infimum 是比該頁中任何記錄都要小的值，而 Supremum 比該頁中最大的記錄值還要大，這兩條記錄在創建頁的時候就有了，並且不會刪除。
所以，在 N0007 和 Suprenum Record 之間加了間隙鎖。
爲什麼不在主鍵上也加 GAP 鎖呢？歡迎留言說出你的想法。
二級非唯一索引，查詢命中
下圖展示了 UPDATE book SET score = 9.2 WHERE Author = 'Tom' 語句在 RC 隔離等級下命中時的加鎖情況。
我們可以看到，在 RC 等級下，二級唯一索引和二級非唯一索引的加鎖情況是一致的，都是在涉及的二級索引和對應的主鍵索引上加上排他記錄鎖。
但是在 RR 隔離等級下，加鎖的情況產生了變化，它不僅對涉及的二級索引和主鍵索引加了排他記錄鎖，還在非唯一二級索引上加了三個間隙鎖，鎖住了兩個 Tom 索引值相關的三個範圍。
那爲什麼唯一索引不需要加間隙鎖呢？間隙鎖的作用是爲了解決幻讀，防止其他事務插入相同索引值的記錄，而唯一索引和主鍵約束都已經保證了該索引值肯定只有一條記錄，所以無需加間隙鎖。
需要注意的是，上圖雖然畫着 4 個記錄鎖，三個間隙鎖，但是實際上間隙鎖和它右側的記錄鎖會合併成 Next-Key 鎖。
所以實際情況有兩個 Next-Key 鎖，一個間隙鎖(Tom60,正無窮)和兩個記錄鎖。
二級非唯一索引，查詢未命中
下圖展示了 UPDATE book SET score = 9.2 WHERE Author = 'Sarah' 在 RR 隔離等級下未命中的加鎖情況，它會在二級索引 Rose 和 Tom 之間加間隙鎖。而 RC 隔離等級下不需要加鎖。
無索引
當 Where 從句的條件並不使用索引時，則會對全表進行掃描，在 RC 隔離等級下對所有的數據加排他記錄鎖。在RR 隔離等級下，除了給記錄加鎖，還會對記錄和記錄之間加間隙鎖。和上邊一樣，間隙鎖會和左側的記錄鎖合併成 Next-Key 鎖。
下圖就是 UPDATE book SET score = 9.2 WHERE score = 22 語句在兩種隔離等級下的加鎖情況。
聚簇索引，範圍查詢
上面介紹的場景都是 where 從句的等值查詢，而範圍查詢的加鎖又是怎麼樣的呢？我們慢慢來看。
下圖是 UPDATE book SET score = 9.2 WHERE ID <= 25 在 RC 和 RR 隔離等級下的加鎖情況。
RC 場景下與等值查詢類似，只會在涉及的 ID = 10，ID = 18 和 ID = 25 索引上加排他記錄鎖。
而在 RR 隔離等級下則有所不同，它會加上間隙鎖，和對應的記錄鎖合併稱爲 Next-Key 鎖。除此之外，它還會在(25, 30] 上分別加 Next-Key 鎖。這一點是十分特殊的，具體原因還需要再探究。
二級索引，範圍查詢
下圖展示了 UPDATE book SET ISBN = N0001 WHERE score <= 7.9 在 RR 級別下的加鎖情況。
修改索引值
UPDATE 語句修改索引值的情況可以分開分析，首先 Where 從句的加鎖分析如上文所述，多了一步 Set 部分的加鎖。
下圖展示了 UPDATE book SET Author = 'John' WHERE ID = 10 在 RC 和 RR 隔離等級下的加鎖情況。除了在主鍵 ID 上進行加鎖，還會對二級索引上的 Bob(就值) 和 John(新值) 上進行加鎖。
DELETE 語句加鎖分析
一般來說，DELETE 的加鎖和 SELECT FOR UPDATE 或 UPDATE 並沒有太大的差異。
因爲，在 MySQL 數據庫中，執行 DELETE 語句其實並沒有直接刪除記錄，而是在記錄上打上一個刪除標記，然後通過後臺的一個叫做 purge 的線程來清理。從這一點來看，DELETE 和 UPDATE 確實是非常相像。事實上，DELETE 和 UPDATE 的加鎖也幾乎是一樣的。
INSERT 語句加鎖分析
接下來，我們來看一下 Insert 語句的加鎖情況。
Insert 語句在兩種情況下會加鎖：
- 爲了防止幻讀，如果記錄之間加有間隙鎖，此時不能 Insert；
- 如果 Insert 的記錄和已有記錄造成唯一鍵衝突，此時不能 Insert；
除了上述情況，Insert 語句的鎖都是隱式鎖。隱式鎖是 InnoDB 實現的一種延遲加鎖的機制來減少加鎖的數量。
隱式鎖的特點是隻有在可能發生衝突時才加鎖，減少了鎖的數量。另外，隱式鎖是針對被修改的 B+Tree 記錄，因此都是記錄類型的鎖，不可能是間隙鎖或 Next-Key 類型。
具體 Insert 語句的加鎖流程如下：
- 首先對插入的間隙加插入意向鎖（Insert Intension Locks）如果該間隙已被加上了間隙鎖或 Next-Key 鎖，則加鎖失敗進入等待；如果沒有，則加鎖成功，表示可以插入；
- 然後判斷插入記錄是否有唯一鍵，如果有，則進行唯一性約束檢查如果不存在相同鍵值，則完成插入如果存在相同鍵值，則判斷該鍵值是否加鎖如果沒有鎖， 判斷該記錄是否被標記爲刪除如果標記爲刪除，說明事務已經提交，還沒來得及 purge，這時加 S 鎖等待；如果沒有標記刪除，則報 duplicate key 錯誤；如果有鎖，說明該記錄正在處理（新增、刪除或更新），且事務還未提交，加 S 鎖等待；
- 插入記錄並對記錄加 X 記錄鎖；
後記
本文中講解的 SQL 語句都是十分簡單的，當 SQL 語句包含多個查詢條件時，加鎖的分析過程就往往更加複雜。我們需要使用 MySQL 相關的工具進行分析，並且有時甚至需要查詢 MySQL 相關的日誌信息來了解到底語句加了什麼鎖或者爲什麼產生死鎖，下篇文章中我們就主要了解一下這些內容，請大家持續關注。