在當(dāng)今的數(shù)據(jù)庫世界中，MySQL 以其強(qiáng)大的功能和廣泛的應(yīng)用備受矚目。而其中的 MVCC（多版本并發(fā)控制）和事務(wù)隔離級別更是關(guān)鍵且核心的概念，它們猶如數(shù)據(jù)庫運(yùn)行的精密齒輪，協(xié)同作用確保著數(shù)據(jù)的完整性、一致性和高效的并發(fā)處理。

當(dāng)我們深入探究 MySQL 的內(nèi)部機(jī)制時(shí)，MVCC 展現(xiàn)出其獨(dú)特的魅力，它巧妙地解決了并發(fā)操作中可能產(chǎn)生的諸多問題。與此同時(shí)，事務(wù)隔離級別則為不同場景下的數(shù)據(jù)處理提供了靈活而精準(zhǔn)的規(guī)則框架。理解這兩者，不僅是對 MySQL 技術(shù)精髓的把握，更是開啟高效數(shù)據(jù)庫應(yīng)用和系統(tǒng)開發(fā)的關(guān)鍵鑰匙。在接下來的篇章中，我們將一同踏上這場解析 MySQL MVCC 和事務(wù)隔離級別的精彩之旅，逐步揭開它們神秘的面紗，探尋其背后蘊(yùn)含的深刻原理和實(shí)際應(yīng)用價(jià)值。

一、詳解事務(wù)的基本概念

1.. 什么是事務(wù)

現(xiàn)在我們開發(fā)的一個(gè)功能需要進(jìn)行操作多張表，假如我們遇到以下幾種情況:

• 某個(gè)邏輯報(bào)錯(cuò)
• 數(shù)據(jù)庫連接中斷
• 某臺服務(wù)器突然宕機(jī)
• .......

這時(shí)候我們數(shù)據(jù)庫執(zhí)行的操作可能才到一半，所以為了避免這種一半一半的情況，我們就需要事務(wù)來保證數(shù)據(jù)一致性。 所以事務(wù)就是當(dāng)作一個(gè)原子的邏輯組操作，要么全都成功執(zhí)行，要么全部都失敗。事務(wù)有分分布式事務(wù)和數(shù)據(jù)庫事務(wù)，如果沒有特指，我們平時(shí)所說的事務(wù)都是數(shù)據(jù)庫事務(wù)，也就是本文探討的話題。

2. 事務(wù)的四大特性

原子可以看作事務(wù)的最小單位，而原子性(Atomicity)的概念即要求一組復(fù)合操作要構(gòu)成一個(gè)原子，不可在進(jìn)行分割了，要么都執(zhí)行成功，要么都不執(zhí)行直接回滾。

隔離性(Isolation)要求在并發(fā)場景下，每個(gè)事務(wù)之間的操作互不干擾，即我們事務(wù)的操作，不會影響到其它是事務(wù)的操作結(jié)果。

持久性(Durability):存儲到數(shù)據(jù)庫中的數(shù)據(jù)永不丟失，及時(shí)數(shù)據(jù)庫發(fā)生故障，當(dāng)然機(jī)器被破壞了那就另說了。

一致性是一個(gè)比較特殊的概念，和AID不同的是，它并非數(shù)據(jù)庫的特性，按照權(quán)威的說法：

ensuring the consistency is the responsibility of user, not DBMS.", "DBMS assumes that consistency holds for each transaction

即一致性要求，從一個(gè)正確的狀態(tài)轉(zhuǎn)換為另一個(gè)正確的狀態(tài)，它并不是DBMS負(fù)責(zé)的范疇，而是通過DB的AID特定來做到這個(gè)C。

我們以轉(zhuǎn)賬業(yè)務(wù)為例說明一下轉(zhuǎn)賬操作在系統(tǒng)中的過程：

• 轉(zhuǎn)賬方余額扣除轉(zhuǎn)賬的金額。
• 收款方加上轉(zhuǎn)賬的金額。

假設(shè)我們手里又90元，希望通過系統(tǒng)轉(zhuǎn)賬100到另一個(gè)賬戶上，如果這個(gè)操作成功，那么我們的賬戶就會變?yōu)?10元，而另一個(gè)賬戶多了100元。

很明顯這種操作并不符合上述所說的從一個(gè)正確的狀態(tài)轉(zhuǎn)為另一個(gè)正確的狀態(tài)，我們必須做到在業(yè)務(wù)發(fā)現(xiàn)轉(zhuǎn)賬方余額小于轉(zhuǎn)賬額度時(shí)，將所有事務(wù)中的操作回滾，避免出現(xiàn)上述那種賬戶余額負(fù)數(shù)的非正確狀態(tài)的情況。

這也就是我們上文所說的，通過MySQL的AID來保證C，C是目的，AID是手段，由此保證應(yīng)用層面業(yè)務(wù)能夠從正確的狀態(tài)轉(zhuǎn)為另一個(gè)正確的狀態(tài)，以保證業(yè)務(wù)的約束，從而做到一致性。

3. 并發(fā)事務(wù)帶來那些問題

這里筆者先說一個(gè)概念，具體會在后文示例中詳盡介紹

臟讀：我們舉個(gè)例子：

• 我們開啟一個(gè)事務(wù)A，準(zhǔn)備讀取user表的數(shù)據(jù)。
• 此時(shí)，事務(wù)B將事務(wù)A要讀取的數(shù)據(jù)修改了，但事務(wù)還沒提交.
• A卻能看到這個(gè)未提交的結(jié)果即sex為1(而且這個(gè)結(jié)果后續(xù)還不一定提交)。

這種其他事務(wù)還沒提交的結(jié)果能被另一個(gè)事務(wù)看到的情況就屬于臟讀。

幻讀:我們再舉個(gè)例子:

• 事務(wù)A查詢user表，此時(shí)表中有10條數(shù)據(jù)。
• 在此期間，事務(wù)B插入5條數(shù)據(jù)。
• 事務(wù)A再次查發(fā)現(xiàn)有15條事務(wù)。

這種同一次事務(wù)兩次查詢結(jié)果不一致的情況是幻讀:

不可重復(fù)讀,仍然舉一個(gè)例子：

• 事務(wù)A讀取id為1的數(shù)據(jù)，name為xiaoming。
• 事務(wù)B在此期間更新id為1的數(shù)據(jù)并提交這個(gè)事務(wù)
• 結(jié)果事務(wù)A再次讀取時(shí)發(fā)現(xiàn)name變了。 這就是不可重復(fù)讀。

你可能會問了，這和幻讀聽起來是一個(gè)概念啊，他倆有什么區(qū)別？ 幻讀說是針對插入或者刪除操作后導(dǎo)致數(shù)據(jù)前后不一致的情況，而不可重復(fù)讀是針對兩次相同查詢操作出現(xiàn)數(shù)據(jù)不一致。也就是說幻讀更多是強(qiáng)調(diào)前后數(shù)據(jù)集的不一致和不可重復(fù)讀更多是強(qiáng)調(diào)數(shù)據(jù)行上的前后不一致。

數(shù)據(jù)丟失：這個(gè)就很好理解了，高并發(fā)場景下，事務(wù)A修改id為1的money+100，事務(wù)B修改id為1的money+200，他們統(tǒng)一時(shí)間讀取，先后寫入，這就導(dǎo)致如果事務(wù)A后寫入，那么money最后只加了100，如果事務(wù)B后寫入，那么money就少了100。

二、詳解事務(wù)的隔離級別

1. 讀未提交(READ UNCOMMITTED)

在這個(gè)級別下，任何事務(wù)的修改操作即使沒有提交，其他事務(wù)也能看到，造成我們上述所說的臟讀，對此我們不妨用下面這段SQL來驗(yàn)證一下:

首先我們先建個(gè)測試表：

create table test2 (id int,name varchar(10),money int); 
insert into test2 values(1,'xiaoming',100);
insert into test2 values(2,'xiaowang',100);

事務(wù)A開啟事務(wù)，進(jìn)行test2  的更新操作，不提交：

start transaction;
-- 小明+100元
update test2   set money = money +100 where name ='xiaoming';
-- 小王減100元
update test2   set money =money -100 where name ='xiaowang';

事務(wù)B設(shè)置為讀未提交的隔離級別：

SET SESSION TRANSACTION ISOLATION LEVEL READ committed;
select * from test2 t ;

查詢結(jié)果是事務(wù)B看到了事務(wù)A的更新操作，造成臟讀。

對應(yīng)結(jié)果如下：

id|name    |money|
--+--------+-----+
 1|xiaoming|  200|
 2|xiaowang|    0|

同理這個(gè)讀未提交，也會造成：

• 幻讀(同一個(gè)事務(wù)同一次查詢記錄數(shù)不一樣)
• 不可重復(fù)讀(同一個(gè)事務(wù)下查詢記錄的值不一樣)

2. 讀已提交(READ COMMITTED)

這個(gè)概念也很好理解，每個(gè)事務(wù)只能看到其他事務(wù)提交后的數(shù)據(jù)。避免了臟讀，但是無法避免幻讀和不可重復(fù)讀。 我們就以幻讀為例，如下圖，事務(wù)B首先查詢到數(shù)據(jù)表中沒有id為1的用戶，在這個(gè)查詢結(jié)束后，事務(wù)A進(jìn)行一次插入操作但是事務(wù)還未提交。

然后事務(wù)A將數(shù)據(jù)提交，事務(wù)B再次查詢就發(fā)現(xiàn)了數(shù)據(jù)，出現(xiàn)幻讀：

了解流程之后，我們拿SQL印證一下，首先創(chuàng)建數(shù)據(jù)表：

drop table if exists account1;


CREATE TABLE `account1` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(50) DEFAULT NULL,
  `balance` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `account1_un` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=UTF8MB4;

事務(wù)B查詢，沒數(shù)據(jù)：

SET SESSION TRANSACTION ISOLATION LEVEL READ committed;
START TRANSACTION;

-- 查詢表，此時(shí)沒有數(shù)據(jù)
SELECT * from account1;

事務(wù)A在此期間插入，事務(wù)不提交：

SET SESSION TRANSACTION ISOLATION LEVEL READ committed;
START TRANSACTION;
-- 在上一個(gè)事務(wù)查詢后，插入一條事務(wù)但是不提交
insert into account1(id,name,balance) values(1,'zhangsan',1000);

此時(shí)事務(wù)B還是沒看到數(shù)據(jù)，然后我們將上述的事務(wù)A數(shù)據(jù)commit，事務(wù)B看到這條數(shù)據(jù)出現(xiàn)幻讀：

3. 可重復(fù)讀(REPEATABLE READ)

這個(gè)隔離級別，也很好理解，同一個(gè)事務(wù)內(nèi)，多次查詢的數(shù)據(jù)都是一樣的。我們不妨基于上面的例子實(shí)驗(yàn)一下。

首先事務(wù)B查詢，沒有任何數(shù)據(jù)：

SET SESSION TRANSACTION ISOLATION LEVEL  REPEATABLE READ;
START TRANSACTION;
select * from account1 a  where id=3;

此時(shí)xiaoming的數(shù)據(jù)為300:

id|name    |balance|
--+--------+-------+
 3|xiaoming|    100|

事務(wù)A執(zhí)行更新并提交：

SET SESSION TRANSACTION ISOLATION LEVEL  REPEATABLE READ;
START TRANSACTION;
update account1 set balance=0 where id=3;
commit;

事務(wù)B再查數(shù)據(jù)還是不變，還是300：

id|name    |balance|
--+--------+-------+
 3|xiaoming|    100|

總的來說可重復(fù)讀避免了臟讀和不可重復(fù)讀，但是幻讀還是無法避免：

4. 串行化(SERIALIZABLE)

事務(wù)隔離最高級別，通過鎖的方式控制并發(fā)流程，解決上述一切問題。

三、詳解MVCC(多版本并發(fā)控制)

1. 當(dāng)前讀和快照讀

快照讀：即讀取數(shù)據(jù)是從快照中獲取的，事務(wù)在進(jìn)行事務(wù)讀取時(shí)不上鎖，這就是mysql并發(fā)讀寫性能高的原因之一。

而當(dāng)前讀反之，讀取數(shù)據(jù)時(shí)會上鎖，這也就意味著即使你的隔離級別是可重復(fù)讀，你用當(dāng)前讀也能讀取到其他事務(wù)的最新結(jié)果，造成不可重復(fù)讀。

我們舉個(gè)例子，首先事務(wù)A讀取數(shù)據(jù)，假設(shè)數(shù)據(jù)值是100:

begin;
-- 讀取到a的money為100
select * from account1 a ;

事務(wù)B更新事務(wù)并提交:

update account1 set mnotallow=1000 where id=1;

事務(wù)A使用快照讀，數(shù)據(jù)還是100:

select * from account1 a ; --快照讀 舊數(shù)據(jù)

一旦使用當(dāng)前讀，就是其他事務(wù)提交的新數(shù)據(jù)了:

--兩個(gè)都是當(dāng)前讀，得到最新結(jié)果
select * from account1 a for update; 
select * from account1 a lock in share mode;

2. undo.log概念掃盲

首先說說undo log，在innoDB的聚簇索引中，每一條記錄除了我們表中的數(shù)據(jù)以外，還會額外記錄名為事務(wù)id(transaction id)的隱藏列。每當(dāng)用戶對當(dāng)前數(shù)據(jù)進(jìn)行修改操作后，新值的數(shù)據(jù)的事務(wù)id就會遞增。 同時(shí)每行數(shù)據(jù)還有一個(gè)回滾指針(roll_pointer)，如下圖所示，每當(dāng)用戶對索引進(jìn)行更新之后，舊的數(shù)據(jù)就會被存放到undo log中，新的數(shù)據(jù)的回滾指針指向這條最新的舊數(shù)據(jù)(就是剛剛存到undo log中的數(shù)據(jù)，通俗的說是最新的垃圾)，用于后續(xù)可能需要的回滾操作：

3. readView概念掃盲

接下來就說說readView，readView就是真正用到undo log的東西，如下圖所示，它由三個(gè)部分組成，分別是:

• 已提交事務(wù):已提交事務(wù)中記錄的則是已經(jīng)被提交的事務(wù)id集合。
• 活躍事務(wù):這個(gè)則記錄那些還能活動且還沒被提交的事務(wù)，其中min_trx_id指向活躍事務(wù)的最小值。
• 未開始事務(wù):這里面則是存放待使用的事務(wù)id值，其中max_trx_id就是記錄這一塊的最小值。

4. 基于可重復(fù)讀版本理解SQL的MVCC工作機(jī)制

了解了undo.log和readView，我們就可以了解mvcc的工作機(jī)制了。就先以可重復(fù)讀RR為例，我們來了解一下如何結(jié)合undo.log和readView實(shí)現(xiàn)可重復(fù)讀的。

可重復(fù)讀這個(gè)級別的readView只會在事務(wù)剛剛開始時(shí)創(chuàng)建，這也就意味著后續(xù)數(shù)據(jù)無論怎么變化，readView都以第一次創(chuàng)建的為主：

假設(shè)我們現(xiàn)在account表數(shù)據(jù)存在一條id為1的數(shù)據(jù)xiaoming，然后事務(wù)trx_id為100的事務(wù)基于RR級別將name先更新為xiaoming_50然后再更新為xiaoming_100，但是事務(wù)還沒提交，此時(shí)對應(yīng)的版本鏈如下所示：

需要注意的是，只有進(jìn)行SQL修改操作即insert、update、delete才會分配一個(gè)事務(wù)id，所以我們本在進(jìn)行查詢之前執(zhí)行一些無關(guān)緊要的update操作，生成一個(gè)事務(wù)200開始查詢執(zhí)行下面這條sql查詢，即查詢id為1的數(shù)據(jù):

-- 執(zhí)行一些無關(guān)緊要的update
select * from account1 a where id=1;

然后事務(wù)啟動創(chuàng)建readView，結(jié)合版本鏈記錄來看，活躍但是未提交事務(wù)值為100，即min_trx_id為100，而我們的事務(wù)為200，這也就意味著max_trx_id為201，由此可得活躍未提交的讀寫事務(wù)m_ids列表有100、200之間。

所以事務(wù)200生成readView如下，然后順著版本鏈開始獲取數(shù)據(jù)首先看到xiaoming_100事務(wù)id為100處于活躍事務(wù)列表不符合要求繼續(xù)順著指針往下走，看到xiaoming_50也不符合要求，繼續(xù)順著指針往下走，看到xiaoming事務(wù)id值為80小于min_trx_id即已提交的事務(wù)中的值，所以我們事務(wù)id為200查詢結(jié)果就是xiaoming:

此時(shí)事務(wù)100將更新結(jié)果提交，因?yàn)榭芍貜?fù)讀生成readView永遠(yuǎn)是以第一次創(chuàng)建時(shí)候?yàn)橹鳎@也就意味著查詢的思路還是和上述步驟一樣，查詢結(jié)果仍然是trx_id為80的xiaoming，這里就不多做贅述了。

5. 基于讀已提交版本readView理解SQL的MVCC工作機(jī)制

讀已提交版本會在每次執(zhí)行查詢時(shí)生成一個(gè)readView，我們還是以上面的例子進(jìn)行演示，還是事務(wù)100觸發(fā)修改但是還沒提交，對應(yīng)生成的版本鏈如下：

還是同理，執(zhí)行一些無關(guān)緊要的修改操作生成本次的事務(wù)id為200然后開始查詢，因?yàn)槭聞?wù)100沒有提交，所以活躍的事務(wù)列表數(shù)據(jù)為100、200生成readView如下：

所以順著版本鏈查詢到結(jié)果也是小于min_trx_id最大值為80，最終查詢結(jié)果為xiaoming。

然后事務(wù)100將結(jié)果提交，此時(shí)我們的事務(wù)200再次進(jìn)行查詢，由讀已提交生成readView為每次查詢時(shí)可得，事務(wù)100已提交所以該事務(wù)處于已提交事務(wù)范圍，然后我們的事務(wù)200還未提交，所以處于活躍事務(wù)列表中，所以活躍事務(wù)列表只有我們的事務(wù)200：

由此順著版本鏈定位到小于min_trx_id的最大值為100，順著版本鏈定位到的第一個(gè)trx_id為100的結(jié)果是xiaoming_100，所以事務(wù)200查詢結(jié)果就是xiaoming_100。

四、關(guān)于MySQL事務(wù)一些常見問題

1. MySQL 的隔離級別是基于鎖實(shí)現(xiàn)的嗎

是基于鎖和mvcc共同實(shí)現(xiàn)的，SERIALIZABLE 這個(gè)隔離級別就是基于鎖實(shí)現(xiàn)的，其他隔離級別都是基于mvcc，需要補(bǔ)充的是REPEATABLE-READ 如果使用當(dāng)前讀也是基于鎖實(shí)現(xiàn)。

2. MySQL 的默認(rèn)隔離級別是什么

以筆者使用的MySQL8來說使用如下命令可以看到默認(rèn)級別為可重復(fù)讀：

select @@transaction_isolation;

對應(yīng)輸出結(jié)果如下：

@@transaction_isolation|
-----------------------+
REPEATABLE-READ        |

五、小結(jié)

MySQL 的 MVCC（多版本并發(fā)控制）是其實(shí)現(xiàn)高效并發(fā)處理的關(guān)鍵機(jī)制。

通過 MVCC，在并發(fā)讀寫操作時(shí)，讀操作不會阻塞寫操作，寫操作也不會阻塞讀操作，極大地提高了數(shù)據(jù)庫的并發(fā)性和性能。

它允許事務(wù)讀取到特定版本的數(shù)據(jù)，實(shí)現(xiàn)了事務(wù)隔離級別的靈活控制。使得不同的事務(wù)可以看到符合其隔離級別要求的數(shù)據(jù)視圖。

在 MVCC 中，每行數(shù)據(jù)都有多個(gè)版本，記錄了不同事務(wù)對其的修改歷史。這種方式有效地避免了鎖競爭帶來的性能開銷和潛在的死鎖問題。

對于理解和優(yōu)化數(shù)據(jù)庫的并發(fā)操作，MVCC 是一個(gè)至關(guān)重要的概念。深入研究和掌握它，有助于更好地設(shè)計(jì)和管理數(shù)據(jù)庫系統(tǒng)，確保數(shù)據(jù)的一致性和高效性。