show engines \G;

show variables like '%storage_engine%';

小明大概了解了一下InnoDB和MyIsAM的區(qū)別，由于使用的是InnoDB，小明就沒有過多的糾結這一塊。

2.2事務的隔離性

小明在研究鎖之前，又回想到之前上學的時候教過的數(shù)據(jù)庫事務隔離性，其實鎖在數(shù)據(jù)庫中其功能之一也是用來實現(xiàn)事務隔離性。而事務的隔離性其實是用來解決，臟讀，不可重復讀，幻讀幾類問題。

2.2.1 臟讀

一個事務讀取到另一個事務未提交的更新數(shù)據(jù)。 什么意思呢?

在事務A，B中，事務A在時間點2，4分別對user表中id=1的數(shù)據(jù)進行了查詢了，但是事務B在時間點3進行了修改，導致了事務A在4中的查詢出的結果其實是事務B修改后的。破壞了數(shù)據(jù)庫中的隔離性。

2.2.2 不可重復讀

在同一個事務中，多次讀取同一數(shù)據(jù)返回的結果不同，和臟讀不同的是這里讀取的是已經(jīng)提交過后的。

在事務B中提交的操作在事務A第二次查詢之前，但是依然讀到了事務B的更新結果，也破壞了事務的隔離性。 

2.2.3 幻讀

一個事務讀到另一個事務已提交的insert數(shù)據(jù)。

在事務A中查詢了兩次id大于1的，在第一次id大于1查詢結果中沒有數(shù)據(jù)，但是由于事務B插入了一條Id=2的數(shù)據(jù)，導致事務A第二次查詢時能查到事務B中插入的數(shù)據(jù)。

事務中的隔離性:

小明注意到在收集資料的過程中，有資料寫到InnoDB和其他數(shù)據(jù)庫有點不同，InnoDB的可重復讀其實就能解決幻讀了，小明心想:這InnoDB還挺牛逼的，我得好好看看到底是怎么個原理。

2.3 InnoDB鎖類型

小明首先了解一下Mysql中常見的鎖類型有哪些:

2.3.1 S or X

在InnoDb中實現(xiàn)了兩個標準的行級鎖，可以簡單的看為兩個讀寫鎖:

• S-共享鎖：又叫讀鎖，其他事務可以繼續(xù)加共享鎖，但是不能繼續(xù)加排他鎖。
• X-排他鎖: 又叫寫鎖，一旦加了寫鎖之后，其他事務就不能加鎖了。

兼容性:是指事務A獲得一個某行某種鎖之后，事務B同樣的在這個行上嘗試獲取某種鎖，如果能立即獲取，則稱鎖兼容，反之叫沖突。

縱軸是代表已有的鎖，橫軸是代表嘗試獲取的鎖。

2.3.2 意向鎖

意向鎖在InnoDB中是表級鎖,和他的名字一樣他是用來表達一個事務想要獲取什么。意向鎖分為:

• 意向共享鎖:表達一個事務想要獲取一張表中某幾行的共享鎖。
• 意向排他鎖:表達一個事務想要獲取一張表中某幾行的排他鎖。

這個鎖有什么用呢？為什么需要這個鎖呢？ 首先說一下如果沒有這個鎖，如果要給這個表加上表鎖，一般的做法是去遍歷每一行看看他是否有行鎖，這樣的話效率太低，而我們有意向鎖，只需要判斷是否有意向鎖即可，不需要再去一行行的去掃描。

在InnoDB中由于支持的是行級的鎖，因此InnboDB鎖的兼容性可以擴展如下：

2.3.3 自增長鎖

自增長鎖是一種特殊的表鎖機制，提升并發(fā)插入性能。對于這個鎖有幾個特點:

• 在sql執(zhí)行完就釋放鎖，并不是事務執(zhí)行完。
• 對于Insert...select大數(shù)據(jù)量插入會影響插入性能，因為會阻塞另外一個事務執(zhí)行。
• 自增算法可以配置。

在MySQL5.1.2版本之后，有了很多優(yōu)化，可以根據(jù)不同的模式來進行調(diào)整自增加鎖的方式。小明看到了這里打開了自己的MySQL發(fā)現(xiàn)是5.7之后，于是便輸入了下面的語句,獲取到當前鎖的模式:

mysql> show variables like 'innodb_autoinc_lock_mode';

+--------------------------+-------+

| Variable_name | Value |

+--------------------------+-------+

| innodb_autoinc_lock_mode | 2 |

+--------------------------+-------+

1 row in set (0.01 sec)

在MySQL中innodbautoinclock_mode有3種配置模式：0、1、2，分別對應”傳統(tǒng)模式”, “連續(xù)模式”, “交錯模式”。

• 傳統(tǒng)模式:也就是我們最上面的使用表鎖。
• 連續(xù)模式:對于插入的時候可以確定行數(shù)的使用互斥量，對于不能確定行數(shù)的使用表鎖的模式。
• 交錯模式:所有的都使用互斥量，為什么叫交錯模式呢，有可能在批量插入時自增值不是連續(xù)的，當然一般來說如果不看重自增值連續(xù)一般選擇這個模式，性能是最好的。

2.4InnoDB鎖算法

小明已經(jīng)了解到了在InnoDB中有哪些鎖類型，但是如何去使用這些鎖，還是得靠鎖算法。

2.4.1 記錄鎖(Record-Lock)

記錄鎖是鎖住記錄的，這里要說明的是這里鎖住的是索引記錄，而不是我們真正的數(shù)據(jù)記錄。

• 如果鎖的是非主鍵索引，會在自己的索引上面加鎖之后然后再去主鍵上面加鎖鎖住.
• 如果沒有表上沒有索引(包括沒有主鍵)，則會使用隱藏的主鍵索引進行加鎖。
• 如果要鎖的列沒有索引，則會進行全表記錄加鎖。

2.4.2 間隙鎖

間隙鎖顧名思義鎖間隙，不鎖記錄。鎖間隙的意思就是鎖定某一個范圍，間隙鎖又叫gap鎖，其不會阻塞其他的gap鎖，但是會阻塞插入間隙鎖，這也是用來防止幻讀的關鍵。

2.4.3 next-key鎖

這個鎖本質是記錄鎖加上gap鎖。在RR隔離級別下(InnoDB默認)，Innodb對于行的掃描鎖定都是使用此算法，但是如果查詢掃描中有唯一索引會退化成只使用記錄鎖。為什么呢? 因為唯一索引能確定行數(shù)，而其他索引不能確定行數(shù)，有可能在其他事務中會再次添加這個索引的數(shù)據(jù)會造成幻讀。

這里也說明了為什么Mysql可以在RR級別下解決幻讀。

2.4.4 插入意向鎖

插入意向鎖Mysql官方對其的解釋:

An insert intention lock is a type of gap lock set by INSERT operations prior to row insertion. This lock signals the intent to insert in such a way that multiple transactions inserting into the same index gap need not wait for each other if they are not inserting at the same position within the gap. Suppose that there are index records with values of 4 and 7. Separate transactions that attempt to insert values of 5 and 6, respectively, each lock the gap between 4 and 7 with insert intention locks prior to obtaining the exclusive lock on the inserted row, but do not block each other because the rows are nonconflicting.

可以看出插入意向鎖是在插入的時候產(chǎn)生的,在多個事務同時寫入不同數(shù)據(jù)至同一索引間隙的時候，并不需要等待其他事務完成，不會發(fā)生鎖等待。假設有一個記錄索引包含鍵值4和7，不同的事務分別插入5和6，每個事務都會產(chǎn)生一個加在4-7之間的插入意向鎖，獲取在插入行上的排它鎖，但是不會被互相鎖住，因為數(shù)據(jù)行并不沖突。

這里要說明的是如果有間隙鎖了，插入意向鎖會被阻塞。

2.5 MVCC

MVCC，多版本并發(fā)控制技術。在InnoDB中，在每一行記錄的后面增加兩個隱藏列，記錄創(chuàng)建版本號和刪除版本號。通過版本號和行鎖，從而提高數(shù)據(jù)庫系統(tǒng)并發(fā)性能。

在MVCC中，對于讀操作可以分為兩種讀:

• 快照讀:讀取的歷史數(shù)據(jù)，簡單的select語句，不加鎖，MVCC實現(xiàn)可重復讀，使用的是MVCC機制讀取undo中的已經(jīng)提交的數(shù)據(jù)。所以它的讀取是非阻塞的。
• 當前讀:需要加鎖的語句,update,insert,delete,select...for update等等都是當前讀。

在RR隔離級別下的快照讀，不是以begin事務開始的時間點作為snapshot建立時間點，而是以第一條select語句的時間點作為snapshot建立的時間點。以后的select都會讀取當前時間點的快照值。

在RC隔離級別下每次快照讀均會創(chuàng)建新的快照。

具體的原理是通過每行會有兩個隱藏的字段一個是用來記錄當前事務，一個是用來記錄回滾的指向Undolog。利用undolog就可以讀取到之前的快照，不需要單獨開辟空間記錄。

3.加鎖分析

小明到這里，已經(jīng)學習很多mysql鎖有關的基礎知識，所以決定自己創(chuàng)建一個表搞下實驗。首先創(chuàng)建了一個簡單的用戶表:

CREATE TABLE `user` (

`id` int(11) unsigned NOT NULL AUTO_INCREMENT,

`name` varchar(11) CHARACTER SET utf8mb4 DEFAULT NULL,

`comment` varchar(11) CHARACTER SET utf8 DEFAULT NULL,

PRIMARY KEY (`id`),

KEY `index_name` (`name`)

) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

然后插入了幾條實驗數(shù)據(jù):

insert user select 20,333,333;

insert user select 25,555,555;

insert user select 20,999,999;

數(shù)據(jù)庫事務隔離選擇了RR

3.1 實驗1

小明開啟了兩個事務，進行實驗1.

小明開啟了兩個事務并輸入了上面的語句，發(fā)現(xiàn)事務B居然出現(xiàn)了超時，小明看了一下自己明明是對name = 555這一行進行的加鎖，為什么我想插入name=556給我阻塞了。于是小明打開命令行輸入:

select * from information_schema.INNODB_LOCKS

發(fā)現(xiàn)在事務A中給555加了Next-key鎖，事務B插入的時候會首先進行插入意向鎖的插入，于是得出下面結論:

可以看見事務B由于間隙鎖和插入意向鎖的沖突，導致了阻塞。

3.2 實驗2

小明發(fā)現(xiàn)上面查詢條件用的是普通的非唯一索引，于是小明就試了一下主鍵索引:

居然發(fā)現(xiàn)事務B并沒有發(fā)生阻塞，哎這個是咋回事呢，小明有點疑惑，按照實驗1的套路應該會被阻塞啊，因為25-30之間會有間隙鎖。于是小明又祭出了命令行，發(fā)現(xiàn)只加了X記錄鎖。原來是因為唯一索引會降級記錄鎖，這么做的理由是:非唯一索引加next-key鎖由于不能確定明確的行數(shù)有可能其他事務在你查詢的過程中，再次添加這個索引的數(shù)據(jù)，導致隔離性遭到破壞，也就是幻讀。唯一索引由于明確了唯一的數(shù)據(jù)行，所以不需要添加間隙鎖解決幻讀。

3.3 實驗3

上面測試了主鍵索引，非唯一索引，這里還有個字段是沒有索引，如果對其加鎖會出現(xiàn)什么呢？

的確，如果用沒有索引的數(shù)據(jù)，其會對所有聚簇索引上都加上next-key鎖。

所以大家平常開發(fā)的時候如果對查詢條件沒有索引的，一定進行一致性讀，也就是加鎖讀，會導致全表加上索引，會導致其他事務全部阻塞，數(shù)據(jù)庫基本會處于不可用狀態(tài)。

4.回到事故

4.1 死鎖

小明做完實驗之后總算是了解清楚了加鎖的一些基本套路，但是之前線上出現(xiàn)的死鎖又是什么東西呢？

死鎖:是指兩個或兩個以上的事務在執(zhí)行過程中，因爭奪資源而造成的一種互相等待的現(xiàn)象。說明有等待才會有死鎖，解決死鎖可以通過去掉等待，比如回滾事務。

解決死鎖的兩個辦法:

• 等待超時:當某一個事務等待超時之后回滾該事務，另外一個事務就可以執(zhí)行了，但是這樣做效率較低，會出現(xiàn)等待時間，還有個問題是如果這個事務所占的權重較大，已經(jīng)更新了很多數(shù)據(jù)了，但是被回滾了，就會導致資源浪費。
• 等待圖(wait-for-graph): 等待圖用來描述事務之間的等待關系，當這個圖如果出現(xiàn)回路如下:

就出現(xiàn)回滾，通常來說InnoDB會選擇回滾權重較小的事務，也就是undo較小的事務。

4.2 線上問題

小明到這里，基本需要的基本功都有了，于是在自己的本地表中開始復現(xiàn)這個問題:

可以看見事務A出現(xiàn)被回滾了，而事務B成功執(zhí)行。 具體每個時間點發(fā)生了什么呢?

時間點2:事務A刪除name = '777'的數(shù)據(jù)，需要對777這個索引加上next-Key鎖，但是其不存在，所以只對555-999之間加間隙鎖，同理事務B也對555-999之間加間隙鎖。間隙鎖之間是兼容的。

時間點3:事務A，執(zhí)行Insert操作，首先插入意向鎖，但是555-999之間有間隙鎖，由于插入意向鎖和間隙鎖沖突，事務A阻塞，等待事務B釋放間隙鎖。事務B同理，等待事務A釋放間隙鎖。于是出現(xiàn)了A->B,B->A回路等待。

時間點4:事務管理器選擇回滾事務A，事務B插入操作執(zhí)行成功。

4.3 修復BUG

這個問題總算是被小明找到了，就是因為間隙鎖，現(xiàn)在需要解決這個問題，這個問題的原因是出現(xiàn)了間隙鎖，那就來去掉他吧:

• 方案一:隔離級別降級為RC，在RC級別下不會加入間隙鎖，所以就不會出現(xiàn)毛病了，但是在RC級別下會出現(xiàn)幻讀，可提交讀都破壞隔離性的毛病，所以這個方案不行。
• 方案二:隔離級別升級為可序列化，小明經(jīng)過測試后發(fā)現(xiàn)不會出現(xiàn)這個問題，但是在可序列化級別下，性能會較低，會出現(xiàn)較多的鎖等待，同樣的也不考慮。
• 方案三:修改代碼邏輯，不要直接刪，改成每個數(shù)據(jù)由業(yè)務邏輯去判斷哪些是更新，哪些是刪除，那些是添加，這個工作量稍大，小明寫這個直接刪除的邏輯就是為了不做這些復雜的事的，所以這個方案先不考慮。
• 方案四:較少的修改代碼邏輯，在刪除之前，可以通過快照查詢(不加鎖)，如果查詢沒有結果，則直接插入，如果有通過主鍵進行刪除，在之前第三節(jié)實驗2中，通過唯一索引會降級為記錄鎖，所以不存在間隙鎖。

經(jīng)過考慮小明選擇了第四種，馬上進行了修復，然后上線觀察驗證，發(fā)現(xiàn)現(xiàn)在已經(jīng)不會出現(xiàn)這個Bug了，這下小明總算能睡個安穩(wěn)覺了。

4.4 如何防止死鎖

小明通過基礎的學習和平常的經(jīng)驗總結了如下幾點:

• 以固定的順序訪問表和行。交叉訪問更容易造成事務等待回路。
• 盡量避免大事務，占有的資源鎖越多，越容易出現(xiàn)死鎖。建議拆成小事務。
• 降低隔離級別。如果業(yè)務允許(上面4.3也分析了，某些業(yè)務并不能允許)，將隔離級別調(diào)低也是較好的選擇，比如將隔離級別從RR調(diào)整為RC，可以避免掉很多因為gap鎖造成的死鎖。
• 為表添加合理的索引。防止沒有索引出現(xiàn)表鎖，出現(xiàn)的死鎖的概率會突增。

最后

由于篇幅有限很多東西并不能介紹全如果感興趣的同學可以閱讀《Mysql技術內(nèi)幕-InnoDB引擎》第6章 以及 何大師的MySQL 加鎖處理分析。作者本人水平有限，如果有什么錯誤，還請指正。

好了，以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對腳本之家的支持。