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

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

一、詳解事務的基本概念

1.. 什么是事務

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

• 某個邏輯報錯
• 數(shù)據(jù)庫連接中斷
• 某臺服務器突然宕機
• .......

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

2. 事務的四大特性

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

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

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

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

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

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

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

• 轉賬方余額扣除轉賬的金額。
• 收款方加上轉賬的金額。

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

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

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

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

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

臟讀：我們舉個例子：

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

這種其他事務還沒提交的結果能被另一個事務看到的情況就屬于臟讀。

幻讀:我們再舉個例子:

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

這種同一次事務兩次查詢結果不一致的情況是幻讀:

不可重復讀,仍然舉一個例子：

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

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

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

二、詳解事務的隔離級別

1. 讀未提交(READ UNCOMMITTED)

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

首先我們先建個測試表：

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

事務A開啟事務，進行test2  的更新操作，不提交：

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

事務B設置為讀未提交的隔離級別：

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

查詢結果是事務B看到了事務A的更新操作，造成臟讀。

對應結果如下：

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

同理這個讀未提交，也會造成：

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

2. 讀已提交(READ COMMITTED)

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

然后事務A將數(shù)據(jù)提交，事務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;

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

SET SESSION TRANSACTION ISOLATION LEVEL READ committed;
START TRANSACTION;

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

事務A在此期間插入，事務不提交：

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

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

3. 可重復讀(REPEATABLE READ)

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

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

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

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

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

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

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

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

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

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

4. 串行化(SERIALIZABLE)

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

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

1. 當前讀和快照讀

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

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

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

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

事務B更新事務并提交:

update account1 set mnotallow=1000 where id=1;

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

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

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

--兩個都是當前讀，得到最新結果
select * from account1 a for update; 
select * from account1 a lock in share mode;

2. undo.log概念掃盲

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

3. readView概念掃盲

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

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

4. 基于可重復讀版本理解SQL的MVCC工作機制

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

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

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

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

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

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

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

此時事務100將更新結果提交，因為可重復讀生成readView永遠是以第一次創(chuàng)建時候為主，這也就意味著查詢的思路還是和上述步驟一樣，查詢結果仍然是trx_id為80的xiaoming，這里就不多做贅述了。

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

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

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

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

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

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

四、關于MySQL事務一些常見問題

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

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

2. MySQL 的默認隔離級別是什么

以筆者使用的MySQL8來說使用如下命令可以看到默認級別為可重復讀：

select @@transaction_isolation;

對應輸出結果如下：

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

五、小結

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

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

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

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

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