前言

前幾天有粉絲和我聊到他找工作面試大廠時被問的問題，因為現(xiàn)在疫情期間，找工作也特別難找。他說面試的題目也比較難，都偏向于一兩年的工作經(jīng)驗的面試題。

他說在一面的時候被問到Mysql的面試題，索引那塊自己都回答比較滿意，但是問到Mysql的鎖機制就比較懵了。

因為平時沒有關(guān)注Mysql的鎖機制，當(dāng)被問到高并發(fā)場景下鎖機制是怎么保證數(shù)據(jù)的一致性的和事務(wù)隔離性的。

他把他面試的過程分享給了我，Mysql高并發(fā)鎖機制的問題，幾乎面大廠都有被問到，Mysql怎么在高并發(fā)下控制并發(fā)訪問的？

我細想了一下，Mysql的鎖機制確實非常重要，所以在這里做一個全面的總結(jié)整理，便于以后的查閱，也分享給各位讀者大大們。

Mysql的鎖機制還是有點難理解的，所以這篇文章采用圖文結(jié)合的方式講解難點，幫助大家理解，講解的主要內(nèi)容如下圖的腦圖所示，基本涵蓋了Mysql鎖機制的所有知識點。

本文腦圖

鎖種類

Mysql中鎖的分類按照不同類型的劃分可以分成不同的鎖，按照「鎖的粒度」劃分可以分成：「表鎖、頁鎖、行鎖」；按照「使用的方式」劃分可以分為：「共享鎖」和「排它鎖」；按照思想的劃分：「樂觀鎖」和「悲觀鎖」。

下面我們對著這幾種劃分的鎖進行詳細的解說和介紹，在了解設(shè)計者設(shè)計鎖的概念的同時，也能深入的理解設(shè)計者的設(shè)計思想。

「表鎖」是粒度最大的鎖，開銷小，加鎖快，不會出現(xiàn)死鎖，但是由于粒度太大，因此造成鎖的沖突幾率大，并發(fā)性能低。

Mysql的「MyISAM儲存引擎就支持表鎖」，MyISAM的表鎖模式有兩種：「表共享讀鎖」和「表獨占寫鎖」。

當(dāng)一個線程獲取到MyISAM表的讀鎖的時候，會阻塞其他用戶對該表的寫操作，但是不會阻塞其它用戶對該用戶的讀操作。

相反的，當(dāng)一個線程獲取到MyISAM表的寫鎖的時候，就會阻塞其它用戶的讀寫操作對其它的線程具有排它性。

「頁鎖」的粒度是介于行鎖和表鎖之間的一種鎖，因為頁鎖是在BDB中支持的一種鎖機制，也很少沒人提及和使用，所以這里制作概述，不做詳解。

「行鎖」是粒度最小的鎖機制，行鎖的加鎖開銷性能大，加鎖慢，并且會出現(xiàn)死鎖，但是行鎖的鎖沖突的幾率低，并發(fā)性能高。

行鎖是InnoDB默認的支持的鎖機制，MyISAM不支持行鎖，這個也是InnoDB和MyISAM的區(qū)別之一。

行鎖在使用的方式上可以劃分為：「共享讀鎖（S鎖）「和」排它寫鎖（X鎖）」。

當(dāng)一個事務(wù)對Mysql中的一條數(shù)據(jù)行加上了S鎖，當(dāng)前事務(wù)不能修改該行數(shù)據(jù)只能執(zhí)行讀操作，其他事務(wù)只能對該行數(shù)據(jù)加S鎖不能加X鎖。

若是一個事務(wù)對一行數(shù)據(jù)加了X鎖，該事務(wù)能夠?qū)υ撔袛?shù)據(jù)執(zhí)行讀和寫操作，其它事務(wù)不能對該行數(shù)據(jù)加任何的鎖，既不能讀也不能寫。

「悲觀鎖和樂觀鎖是在很多框架都存在的一種思想，不要狹義地認為它們是某一種框架的鎖機制」。

數(shù)據(jù)庫管理系統(tǒng)中為了控制并發(fā)，保證在多個事務(wù)執(zhí)行時的數(shù)據(jù)一致性以及事務(wù)的隔離性，使用悲觀鎖和樂觀鎖來解決并發(fā)場景下的問題。

Mysql的「悲觀鎖的實現(xiàn)是基于Mysql自身的鎖機制實現(xiàn)，而樂觀鎖需要程序員自己去實現(xiàn)的鎖機制」，最常見的樂觀鎖實現(xiàn)就鎖機制是「使用版本號實現(xiàn)」。

樂觀鎖設(shè)計思想的在CAS的運用也是比較經(jīng)典，之前我寫過一篇關(guān)于CAS的文章，大家感興趣的可以參考這一篇[深入剖析AQS和CAS，看了都說好]。

從上面的介紹中說了每一種鎖的概念，但是很難說哪一種鎖就是最好的，鎖沒有最好的，只有哪種業(yè)務(wù)場景最適合哪種鎖，具體業(yè)務(wù)具體分析。

下面我們就具體基于Mysql的存儲引擎詳細的分析每一種鎖在存儲引擎中的運用和實現(xiàn)。

MyISAM

MyISAM中默認支持的表級鎖有兩種：「共享讀鎖」和「獨占寫鎖」。表級鎖在MyISAM和InnoDB的存儲引擎中都支持，但是InnoDB默認支持的是行鎖。

Mysql中平時讀寫操作都是隱式的進行加鎖和解鎖操作，Mysql已經(jīng)自動幫我們實現(xiàn)加鎖和解鎖操作了，若是想要測試鎖機制，我們就要顯示的自己控制鎖機制。

Mysql中可以通過以下sql來顯示的在事務(wù)中顯式的進行加鎖和解鎖操作：

// 顯式的添加表級讀鎖
LOCK TABLE 表名 READ
// 顯示的添加表級寫鎖
LOCK TABLE 表名 WRITE
// 顯式的解鎖（當(dāng)一個事務(wù)commit的時候也會自動解鎖）
unlock tables;

下面我們就來測試一下MyISAM中的表級鎖機制，首先創(chuàng)建一個測試表employee ，這里要指定存儲引擎為MyISAM，并插入兩條測試數(shù)據(jù)：

CREATE TABLE IF NOT EXISTS employee (
    id INT PRIMARY KEY auto_increment,
    name VARCHAR(40),
    money INT
)ENGINE MyISAM

INSERT INTO employee(name, money) VALUES('黎杜', 1000);
INSERT INTO employee(name, money) VALUES('非科班的科班', 2000);

查看一下，表結(jié)果如下圖所示：

MyISAM表級寫鎖

（1）與此同時再開啟一個session窗口，然后在第一個窗口執(zhí)行下面的sql，在session1中給表添加寫鎖：

LOCK TABLE employee WRITE

（2）可以在session2中進行查詢或者插入、更新該表數(shù)據(jù)，可以發(fā)現(xiàn)都會處于等待狀態(tài)，也就是session1鎖住了整個表，導(dǎo)致session2只能等待：

（3）在session1中進行查詢、插入、更新數(shù)據(jù)，都可以執(zhí)行成功：

「總結(jié)：」 從上面的測試結(jié)果顯示「當(dāng)一個線程獲取到表級寫鎖后，只能由該線程對表進行讀寫操作，別的線程必須等待該線程釋放鎖以后才能操作」。

MyISAM表級共享讀鎖

（1）接下來測試一下表級共享讀鎖，同樣還是利用上面的測試數(shù)據(jù)，第一步還是在session1給表加讀鎖。

（2）然后在session1中嘗試進行插入、更新數(shù)據(jù)，發(fā)現(xiàn)都會報錯，只能查詢數(shù)據(jù)。

（3）最后在session2中嘗試進行插入、更新數(shù)據(jù)，程序都會進入等待狀態(tài)，只能查詢數(shù)據(jù)，直到session1解鎖表session2才能插入、更新數(shù)據(jù)。

「總結(jié)：」 從上面的測試結(jié)果顯示「當(dāng)一個線程獲取到表級讀鎖后，該線程只能讀取數(shù)據(jù)不能修改數(shù)據(jù)，其它線程也只能加讀鎖，不能加寫鎖」。

MyISAM表級鎖競爭情況

MyISAM存儲引擎中，可以通過查詢變量來查看并發(fā)場景鎖的爭奪情況，具體執(zhí)行下面的sql語句：

show status like 'table%';

主要是查看table_locks_waited和table_locks_immediate的值的大小分析鎖的競爭情況。

Table_locks_immediate：表示能夠立即獲得表級鎖的鎖請求次數(shù)；Table_locks_waited表示不能立即獲取表級鎖而需要等待的鎖請求次數(shù)分析，「值越大競爭就越嚴重」。

并發(fā)插入

通過上面的操作演示，詳細的說明了表級共享鎖和表級寫鎖的特點。但是在平時的執(zhí)行sql的時候，這些「解鎖和釋放鎖都是Mysql底層隱式的執(zhí)行的」。

上面的演示只是為了證明顯式的執(zhí)行事務(wù)的過程共享鎖和表級寫鎖的加鎖和解鎖的特點，實際并不會這么做的。

在我們平時執(zhí)行select語句的時候就會隱式的加讀鎖，執(zhí)行增、刪、改的操作時就會隱式的執(zhí)行加寫鎖。

MyISAM存儲引擎中，雖然讀寫操作是串行化的，但是它也支持并發(fā)插入，這個需要設(shè)置內(nèi)部變量concurrent_insert的值。

它的值有三個值0、1、2?？梢酝ㄟ^以下的sql查看concurrent_insert的默認值為「AUTO(或者1)」。

concurrent_insert的值為NEVER (or 0)表示不支持比并發(fā)插入；值為AUTO(或者1）表示在MyISAM表中沒有被刪除的行，運行另一個線程從表尾插入數(shù)據(jù)；值為ALWAYS (or 2)表示不管是否有刪除的行，都允許在表尾插入數(shù)據(jù)。

鎖調(diào)度

MyISAM存儲引擎中，「假如同時一個讀請求，一個寫請求過來的話，它會優(yōu)先處理寫請求」，因為MyISAM存儲引擎中認為寫請求比讀請求重要。

這樣就會導(dǎo)致，「假如大量的讀寫請求過來，就會導(dǎo)致讀請求長時間的等待，或者"線程餓死"，因此MyISAM不適合運用于大量讀寫操作的場景」，這樣會導(dǎo)致長時間讀取不到用戶數(shù)據(jù)，用戶體驗感極差。

當(dāng)然可以通過設(shè)置low-priority-updates參數(shù)，設(shè)置請求鏈接的優(yōu)先級，使得Mysql優(yōu)先處理讀請求。

InnoDB

InnoDB和MyISAM不同的是，InnoDB支持「行鎖」和「事務(wù)」，行級鎖的概念前面以及說了，這里就不再贅述，事務(wù)的四大特性的概述以及實現(xiàn)的原理可以參考這一篇[]。

InnoDB中除了有「表鎖」和「行級鎖」的概念，還有Gap Lock（間隙鎖）、Next-key Lock鎖，「間隙鎖主要用于范圍查詢的時候，鎖住查詢的范圍，并且間隙鎖也是解決幻讀的方案」。

InnoDB中的行級鎖是「對索引加的鎖，在不通過索引查詢數(shù)據(jù)的時候，InnoDB就會使用表鎖」。

「但是通過索引查詢的時候是否使用索引，還要看Mysql的執(zhí)行計劃」，Mysql的優(yōu)化器會判斷是一條sql執(zhí)行的最佳策略。

若是Mysql覺得執(zhí)行索引查詢還不如全表掃描速度快，那么Mysql就會使用全表掃描來查詢，這是即使sql語句中使用了索引，最后還是執(zhí)行為全表掃描，加的是表鎖。

若是對于Mysql的sql執(zhí)行原理不熟悉的可以參考這一篇文章[]。最后是否執(zhí)行了索引查詢可以通過explain來查看，我相信這個大家都是耳熟能詳?shù)拿盍恕?/p>

InnoDB行鎖和表鎖

InnoDB的行鎖也是分為行級「共享讀鎖（S鎖）「和」排它寫鎖（X鎖）」，原理特點和MyISAM的表級鎖兩種模式是一樣的。

若想顯式的給表加行級讀鎖和寫鎖，可以執(zhí)行下面的sql語句：

// 給查詢sql顯示添加讀鎖
select ... lock in share mode;
// 給查詢sql顯示添加寫鎖
select ... for update；

（1）下面我們直接進入鎖機制的測試階段，還是創(chuàng)建一個測試表，并插入兩條數(shù)據(jù)：

// 先把原來的MyISAM表給刪除了
DROP TABLE IF EXISTS employee;
CREATE TABLE IF NOT EXISTS employee (
    id INT PRIMARY KEY auto_increment,
    name VARCHAR(40),
    money INT
)ENGINE INNODB;
// 插入測試數(shù)據(jù)
INSERT INTO employee(name, money) VALUES('黎杜', 1000);
INSERT INTO employee(name, money) VALUES('非科班的科班', 2000);

（2）創(chuàng)建的表中可以看出對表中的字段只有id添加了主鍵索引，接著就是在session1窗口執(zhí)行begin開啟事務(wù)，并執(zhí)行下面的sql語句：

// 使用非索引字段查詢，并顯式的添加寫鎖
select * from employee where name='黎杜' for update;

（3）然后在session2中執(zhí)行update語句，上面查詢的是id=1的數(shù)據(jù)行，下面update的是id=2的數(shù)據(jù)行，會發(fā)現(xiàn)程序也會進入等待狀態(tài)：

update employee set name='ldc' where id =2;

可見若是「使用非索引查詢，直接就是使用的表級鎖」，鎖住了整個表。

（4）若是session1使用的是id來查詢，如下圖所示：

（5）那么session2是可以成功update其它數(shù)據(jù)行的，但是這里我建議使用數(shù)據(jù)量大的表進行測試，因為前面我說過了「是否執(zhí)行索引還得看Mysql的執(zhí)行計劃，對于一些小表的操作，可能就直接使用全表掃描」。

（6）還有一種情況就是：假如我們給name字段也加上了普通索引，那么通過普通索引來查詢數(shù)據(jù)，并且查詢到多行數(shù)據(jù)，那它是鎖這多行數(shù)據(jù)還是鎖整個表呢？

下面我們來測試一下，首先給「name字段添加普通索引」，如下圖所示：

（6）并插入一條新的數(shù)據(jù)name值與id=2的值相同，并顯式的加鎖，如下若是：

（7）當(dāng)update其它數(shù)據(jù)行name值不是ldc的也會進入等待狀態(tài)，并且通過explain來查看是否name='ldc'有執(zhí)行索引，可以看到sql語句是有執(zhí)行索引條件的。

結(jié)論：從上面的測試鎖機制的演示可以得出以下幾個結(jié)論：

1. 執(zhí)行非索引條件查詢執(zhí)行的是表鎖。
2. 執(zhí)行索引查詢是否是加行鎖，還得看Mysql的執(zhí)行計劃，可以通過explain關(guān)鍵字來查看。
3. 用普通鍵索引的查詢，遇到索引值相同的，也會對其他的操作數(shù)據(jù)行的產(chǎn)生影響。

InnoDB間隙鎖

當(dāng)我們使用范圍條件查詢而不是等值條件查詢的時候，InnoDB就會給符合條件的范圍索引加鎖，在條件范圍內(nèi)并不存的記錄就叫做"間隙（GAP）"

大家大概都知道在事務(wù)的四大隔離級別中，不可重復(fù)讀會產(chǎn)生幻讀的現(xiàn)象，只能通過提高隔離級別到串行化來解決幻讀現(xiàn)象。

但是Mysql中的不可重復(fù)是已經(jīng)解決了幻讀問題，它通過引入間隙鎖的實現(xiàn)來解決幻讀，通過給符合條件的間隙加鎖，防止再次查詢的時候出現(xiàn)新數(shù)據(jù)產(chǎn)生幻讀的問題。

例如我們執(zhí)行下面的sql語句，就會對id大于100的記錄加鎖，在id>100的記錄中肯定是有不存在的間隙：

Select * from  employee where id> 100 for update;

（1）接著來測試間隙鎖，新增一個字段num，并將num添加為普通索引、修改之前的數(shù)據(jù)使得num之間的值存在間隙，操作如下sql所示：

alter table employee add num int not null default 0;
update employee set num = 1 where id = 1;
update employee set num = 1 where id = 2;
update employee set num = 3 where id = 3;
insert into employee values(4,'kris',4000,5);

（2）接著在session1的窗口開啟事務(wù)，并執(zhí)行下面操作：

（3）同時打開窗口session2，并執(zhí)行新增語句：

insert into employee values(5,'ceshi',5000,2);  // 程序出現(xiàn)等待
insert into employee values(5,'ceshi',5000,4);  // 程序出現(xiàn)等待
insert into employee values(5,'ceshi',5000,6);  // 新增成功
insert into employee values(6,'ceshi',5000,0);  // 新增成功

「從上面的測試結(jié)果顯示在區(qū)間（1,3]U[3,5)之間加了鎖，是不能夠新增數(shù)據(jù)行，這就是新增num=2和num=4失敗的原因，但是在這個區(qū)間以外的數(shù)據(jù)行是沒有加鎖的，可以新增數(shù)據(jù)行」。

根據(jù)索引的有序性，而普通索引是可以出現(xiàn)重復(fù)值，那么當(dāng)我們第一個sesson查詢的時候只出現(xiàn)一條數(shù)據(jù)num=3，為了解決第二次查詢的時候出現(xiàn)幻讀，也就是出現(xiàn)兩條或者更多num=3這樣查詢條件的數(shù)據(jù)。

Mysql在滿足where條件的情況下，給（1,3]U[3,5)區(qū)間加上了鎖不允許插入num=3的數(shù)據(jù)行，這樣就解決了幻讀。

這里拋出幾種情況接著來測試間隙鎖。主鍵索引（唯一索引）是否會加上間隙鎖呢？范圍查詢是否會加上間隙鎖？使用不存在的檢索條件是否會加上間隙鎖？

先來說說：「主鍵索引（唯一索引）是否會加上間隙鎖呢？」

因為主鍵索引具有唯一性，不允許出現(xiàn)重復(fù)，那么當(dāng)進行等值查詢的時候id=3，只能有且只有一條數(shù)據(jù)，是不可能再出現(xiàn)id=3的第二條數(shù)據(jù)。

因此它只要鎖定這條數(shù)據(jù)（鎖定索引），在下次查詢當(dāng)前讀的時候不會被刪除、或者更新id=3的數(shù)據(jù)行，也就保證了數(shù)據(jù)的一致性，所以主鍵索引由于他的唯一性的原因，是不需要加間隙鎖的。

再來說說第二個問題：「范圍查詢是否會加上間隙鎖？」

直接在session1中執(zhí)行下面的sql語句，并在session2中在這個num>=3的查詢條件內(nèi)和外新增數(shù)據(jù)：

select * from employee where num>=3 for update;
insert into employee values(6,'ceshi',5000,2);  // 程序出現(xiàn)等待
insert into employee values(7,'ceshi',5000,4);  // 程序出現(xiàn)等待
insert into employee values(8,'ceshi',5000,1);  // 新增數(shù)據(jù)成功

我們來分析以下原理：單查詢num>=3的時候，在現(xiàn)有的employee表中滿足條件的數(shù)據(jù)行，如下所示：

那么在設(shè)計者的角度出發(fā)，我為了解決幻讀的現(xiàn)象：在num>=3的條件下是必須加上間隙鎖的。

而在小于num=3中，下一條數(shù)據(jù)行就是num=1了，為了防止在（1，3]的范圍中加入了num=3的數(shù)據(jù)行，所以也給這個間隙加上了鎖，這就是添加num=2數(shù)據(jù)行出現(xiàn)等待的原因。

最后來說一說：「使用不存在的檢索條件是否會加上間隙鎖？」

假如是查詢num>=8的數(shù)據(jù)行呢？因為employee表并不存在中num=8的數(shù)據(jù)行，num最大num=6，所以為了解決幻讀（6，8]與num>=8也會加上鎖。

說到這里我相信很多人已經(jīng)對間隙鎖有了清晰和深入的認識，可以說是精通了，又可以和面試官互扯了。

假如你是第一次接觸Mysql的鎖機制，第一次肯定是懵的，建議多認真的看幾遍，跟著案例敲一下自己深刻的去體會，慢慢的就懂了。

死鎖

死鎖在InnoDB中才會出現(xiàn)死鎖，MyISAM是不會出現(xiàn)死鎖，因為MyISAM支持的是表鎖，一次性獲取了所有的鎖，其它的線程只能排隊等候。

而InnoDB默認支持行鎖，獲取鎖是分步的，并不是一次性獲取所有的鎖，因此在鎖競爭的時候就會出現(xiàn)死鎖的情況。

雖然InnoDB會出現(xiàn)死鎖，但是并不影響InnoDB成為最受歡迎的存儲引擎，MyISAM可以理解為串行化操作，讀寫有序，因此支持的并發(fā)性能低下。

死鎖案例一

舉一個例子，現(xiàn)在數(shù)據(jù)庫表employee中六條數(shù)據(jù)，如下所示：

其中name=ldc的有兩條數(shù)據(jù)，并且name字段為普通索引，分別是id=2和id=3的數(shù)據(jù)行，現(xiàn)在假設(shè)有兩個事務(wù)分別執(zhí)行下面的兩條sql語句：

// session1執(zhí)行
update employee set num = 2 where name ='ldc';
// session2執(zhí)行
select * from employee where id = 2 or id =3;

其中session1執(zhí)行的sql獲取的數(shù)據(jù)行是兩條數(shù)據(jù)，假設(shè)先獲取到第一個id=2的數(shù)據(jù)行，然后cpu的時間分配給了另一個事務(wù)，另一個事務(wù)執(zhí)行查詢操作獲取了第二行數(shù)據(jù)也就是id=3的數(shù)據(jù)行。

當(dāng)事務(wù)2繼續(xù)執(zhí)行的時候獲取到id=3的數(shù)據(jù)行，鎖定了id=3的數(shù)據(jù)行，此時cpu又將時間分配給了第一個事務(wù)，第一個事務(wù)執(zhí)行準(zhǔn)備獲取第二行數(shù)據(jù)的鎖，發(fā)現(xiàn)已經(jīng)被其他事務(wù)獲取了，它就處于等待的狀態(tài)。

當(dāng)cpu把時間有分配給了第二個事務(wù)，第二個事務(wù)準(zhǔn)備獲取第一行數(shù)據(jù)的鎖發(fā)現(xiàn)已經(jīng)被第一個事務(wù)獲取了鎖，這樣就行了死鎖，兩個事務(wù)彼此之間相互等待。

死鎖案例二

第二種死鎖情況就是當(dāng)一個事務(wù)開始并且update一條id=1的數(shù)據(jù)行時，成功獲取到寫鎖，此時另一個事務(wù)執(zhí)行也update另一條id=2的數(shù)據(jù)行時，也成功獲取到寫鎖（id為主鍵）。

此時cpu將時間分配給了事務(wù)一，事務(wù)一接著也是update id=2的數(shù)據(jù)行，因為事務(wù)二已經(jīng)獲取到id=2數(shù)據(jù)行的鎖，所以事務(wù)已處于等待狀態(tài)。

事務(wù)二有獲取到了時間，像執(zhí)行update id=1的數(shù)據(jù)行，但是此時id=1的鎖被事務(wù)一獲取到了，事務(wù)二也處于等待的狀態(tài)，因此形成了死鎖。

死鎖的解決方案

首先要解決死鎖問題，在程序的設(shè)計上，當(dāng)發(fā)現(xiàn)程序有高并發(fā)的訪問某一個表時，盡量對該表的執(zhí)行操作串行化，或者鎖升級，一次性獲取所有的鎖資源。

然后也可以設(shè)置參數(shù)innodb_lock_wait_timeout，超時時間，并且將參數(shù)innodb_deadlock_detect 打開，當(dāng)發(fā)現(xiàn)死鎖的時候，自動回滾其中的某一個事務(wù)。

總結(jié)

上面詳細的介紹了MyISAM和InnoDB兩種存儲引擎的鎖機制的實現(xiàn)，并進行了測試。

MyISAM的表鎖分為兩種模式：「共享讀鎖」和「排它寫鎖」。獲取的讀鎖的線程對該數(shù)據(jù)行只能讀，不能修改，其它線程也只能對該數(shù)據(jù)行加讀鎖。

獲取到寫鎖的線程對該數(shù)據(jù)行既能讀也能寫，對其他線程對該數(shù)據(jù)行的讀寫具有排它性。

MyISAM中默認寫優(yōu)先于去操作，因此MyISAM一般不適合運用于大量讀寫操作的程序中。

InnoDB的行鎖雖然會出現(xiàn)死鎖的可能，但是InnoDB的支持的并發(fā)性能比MyISAM好，行鎖的粒度最小，一定的方法和措施可以解決死鎖的發(fā)生，極大的發(fā)揮InnoDB的性能。

InnoDB中引入了間隙鎖的概念來決解出現(xiàn)幻讀的問題，也引入事務(wù)的特性，通過事務(wù)的四種隔離級別，來降低鎖沖突，提高并發(fā)性能。

【文章參考】

[1] https://www.cnblogs.com/leedaily/p/8378779.html

[2] https://blog.csdn.net/qq_38238296/article/details/88362999

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：
長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝