快捷導(dǎo)航

深入探究MySQL事務(wù)實(shí)現(xiàn)原理

更新時(shí)間：2023年06月14日 10:53:25 作者：半畝方塘立身

數(shù)據(jù)庫事務(wù)是指一組數(shù)據(jù)庫操作，這些操作必須被視為一個(gè)不可分割的單元，要么全部執(zhí)行成功，要么全部失敗回滾，本文詳細(xì)的給大家介紹了MySQL事務(wù)的實(shí)現(xiàn)原理，對我們學(xué)習(xí)MySQL有一定的幫助，感興趣的同學(xué)可以跟著小編一起來探究

什么是數(shù)據(jù)庫事務(wù)

數(shù)據(jù)庫事務(wù)是指一組數(shù)據(jù)庫操作，這些操作必須被視為一個(gè)不可分割的單元，要么全部執(zhí)行成功，要么全部失敗回滾。事務(wù)通常由多個(gè)SQL語句組成，這些語句可以讀取、插入、更新或刪除數(shù)據(jù)庫中的數(shù)據(jù)。
事務(wù)具有ACID屬性：

原子性（Atomicity）：事務(wù)的所有操作被視為單個(gè)原子操作，要么全部執(zhí)行成功，要么全部執(zhí)行失敗回滾。
一致性（Consistency）：事務(wù)執(zhí)行的結(jié)果必須使數(shù)據(jù)庫從一個(gè)一致性狀態(tài)轉(zhuǎn)換到另一個(gè)一致性狀態(tài)，其中包括所有數(shù)據(jù)完整性和約束性規(guī)則的應(yīng)用。
隔離性（Isolation）：一個(gè)事務(wù)的執(zhí)行不能被其他并發(fā)執(zhí)行的事務(wù)干擾，每個(gè)事務(wù)應(yīng)該感覺自己在獨(dú)立地執(zhí)行。
持久性（Durability）：一旦事務(wù)提交，其結(jié)果應(yīng)該持久保存在數(shù)據(jù)庫中，即使系統(tǒng)故障也應(yīng)該如此。

通過實(shí)現(xiàn)事務(wù)，數(shù)據(jù)庫系統(tǒng)可以確保數(shù)據(jù)的完整性和一致性，以及并發(fā)訪問時(shí)的正確性。如果一個(gè)事務(wù)中的任何一個(gè)操作失敗，整個(gè)事務(wù)將被回滾到最初的狀態(tài)，這確保了數(shù)據(jù)庫的一致性。

Mysql如何保證原子性

undo log名為回滾日志，是實(shí)現(xiàn)原子性的關(guān)鍵。 InnoDB把這些為了回滾而記錄的這些東西稱之為undo log。這里需要注意的一點(diǎn)是，由于查詢操作（SELECT）并不會修改任何用戶記錄，所以在查詢操作執(zhí)行時(shí)，并不需要記錄相應(yīng)的undo log。undo log主要分為3種：

Insert undo log ：插入一條記錄時(shí)，至少要把這條記錄的主鍵值記下來，之后回滾的時(shí)候只需要把這個(gè)主鍵值對應(yīng)的記錄刪掉就好了。
Update undo log：修改一條記錄時(shí)，至少要把修改這條記錄前的舊值都記錄下來，這樣之后回滾時(shí)再把這條記錄更新為舊值就好了。
Delete undo log：刪除一條記錄時(shí)，至少要把這條記錄中的內(nèi)容都記下來，這樣之后回滾時(shí)再把由這些內(nèi)容組成的記錄插入到表中就好了。
- 刪除操作都只是設(shè)置一下老記錄的DELETED_BIT，并不真正將過時(shí)的記錄刪除。
- 為了節(jié)省磁盤空間，InnoDB有專門的purge線程來清理DELETED_BIT為true的記錄。為了不影響MVCC的正常工作，purge線程自己也維護(hù)了一個(gè)read view（這個(gè)read view相當(dāng)于系統(tǒng)中最老活躍事務(wù)的read view）;如果某個(gè)記錄的DELETED_BIT為true，并且DB_TRX_ID相對于purge線程的read view可見，那么這條記錄一定是可以被安全清除的。

舉個(gè)栗子：

sql	undo log
insert	delete
delete	insert
update T set v=3 where v=1	update T set v=1 where v=3

Mysql如何保證持久性

我們了解到InnoDB 為了提升讀寫效率，引入了Buffer Pool（緩存池）:

當(dāng)數(shù)據(jù)庫讀取數(shù)據(jù)時(shí)，會首先從緩存池中讀取
往數(shù)據(jù)庫寫入數(shù)據(jù)時(shí)，會先寫入緩存池
緩存池中更新的數(shù)據(jù)會定期刷新到磁盤中

如果MySQL宕機(jī)，緩存池中更新的數(shù)據(jù)還沒有刷回到磁盤中，就會導(dǎo)致數(shù)據(jù)丟失。于是，redo log被引入進(jìn)來解決這個(gè)問題。

先將原始數(shù)據(jù)從磁盤中讀入內(nèi)存中來，修改數(shù)據(jù)的內(nèi)存拷貝。
生成一條重做日志并寫入redo log buffer，記錄的是數(shù)據(jù)被修改后的值。
當(dāng)事務(wù)commit時(shí)，將redo log buffer中的內(nèi)容刷新到 redolog file，對 redo log file采用追加寫的方式。
定期將內(nèi)存中修改的數(shù)據(jù)刷新到磁盤中。

redo與undo在一次事務(wù)操作中是如何交互的?假設(shè)有A、B兩個(gè)數(shù)據(jù)，值分別為1、2，開啟事務(wù)分別對其進(jìn)行修改A → 3，B → 4，在提交，過程如下:

事務(wù)	redo&undo logo
begin;	開啟事務(wù)
	記錄A->3到redo log buffer
update T set A=3 where A=1;	A修改為3
	記錄A=1到undo log
	記錄B->4到redo log buffer
update T set B=4 where B=2;	B修改為4
	記錄B=2到undo log
	記錄A->3到redo log記錄B->4到redo log
commit;	事務(wù)提交

MySQL怎么保證隔離性

事務(wù)在并發(fā)情形下會互相干擾到的操作大體可以分為兩類，與之相對應(yīng)地，MySQL采用了兩種方式來實(shí)現(xiàn)它們的隔離:

一個(gè)事務(wù)的寫操作對另一個(gè)事務(wù)的寫操作的影響:鎖機(jī)制保證隔離性
一個(gè)事務(wù)的寫操作對另一個(gè)事務(wù)的讀操作的影響:MVCC保證隔離性

加鎖:讀取數(shù)據(jù)之前，對其加鎖，阻止其他事務(wù)對數(shù)據(jù)進(jìn)行修改

MVCC:不加任何鎖，采用多版本并發(fā)控制實(shí)現(xiàn)，把數(shù)據(jù)庫的行鎖和行的多個(gè)版本結(jié)合起來，可以實(shí)現(xiàn)非鎖定讀，從而提高數(shù)據(jù)庫的并發(fā)性能。

事務(wù)隔離級別

當(dāng)數(shù)據(jù)庫上有多個(gè)事務(wù)同時(shí)執(zhí)行的時(shí)候，會帶來以下問題：

問題	描述	舉例
臟讀	一個(gè)事務(wù)讀到了另一個(gè)事務(wù)未提交修改的數(shù)據(jù)。	事務(wù)A開始一個(gè)更新操作，但是還沒有提交，這時(shí)事務(wù)B讀取了這個(gè)未提交的數(shù)據(jù)，就會產(chǎn)生臟讀。
幻讀	一個(gè)事務(wù)按相同的查詢條件重新讀取以前檢索過的數(shù)據(jù)，卻發(fā)現(xiàn)其他事務(wù)插入了滿足其查詢條件的新數(shù)據(jù)。	事務(wù)A進(jìn)行一個(gè)范圍查詢，此時(shí)事務(wù)B插入了一些符合該范圍查詢條件的新數(shù)據(jù)，當(dāng)事務(wù)A再次進(jìn)行相同的范圍查詢時(shí)，會發(fā)現(xiàn)多了一些之前沒有的行，就產(chǎn)生了幻讀。
不可重復(fù)讀	在一個(gè)事務(wù)中，多次查詢的數(shù)據(jù)不一致。	事務(wù)A讀取了一行數(shù)據(jù)，然后事務(wù)B對這一行數(shù)據(jù)進(jìn)行了更新，并且提交了，當(dāng)事務(wù)A再次讀取這一行數(shù)據(jù)時(shí)，會發(fā)現(xiàn)數(shù)據(jù)已經(jīng)發(fā)生了變化，就產(chǎn)生了不可重復(fù)讀。

為了避免這些問題的出現(xiàn)，數(shù)據(jù)庫引入了隔離級別的概念，通過對不同隔離級別的設(shè)置，可以控制事務(wù)之間的隔離程度，從而避免并發(fā)問題的產(chǎn)生。不同的隔離級別有不同的特點(diǎn)和使用場景，需要根據(jù)實(shí)際情況進(jìn)行選擇。

以下是四個(gè)標(biāo)準(zhǔn)的事務(wù)隔離級別：

隔離級別	含義	臟讀	不可重復(fù)讀	幻讀
讀未提交，Read Uncommitted	事務(wù)中的修改，即使沒有提交，對其他事務(wù)都是可見的	Y	Y	Y
讀已提交，Read Committed	事務(wù)從開始到提交之前，所做的修改對其他事務(wù)都不可見	N	Y	Y
可重復(fù)讀，Repeatable read	同一事務(wù)中多次讀取同樣的記錄結(jié)果是一致的	N	N	Y
可序列化，Serializable	在讀取的每一行數(shù)據(jù)上加鎖，強(qiáng)制事務(wù)串行執(zhí)行	N	N	N

臟讀的解決

Innodb是通過在每行數(shù)據(jù)中增加一個(gè)隱藏的事務(wù)ID來實(shí)現(xiàn)mvcc，當(dāng)一個(gè)事物開始時(shí)他會獲取一個(gè)唯一的事務(wù)ID，該事務(wù)ID用來標(biāo)記事務(wù)做的修改。當(dāng)事務(wù)讀取一行數(shù)據(jù)時(shí)，innodb會檢查該行數(shù)據(jù)事務(wù)ID是否小于當(dāng)前事務(wù)ID，如果是說明該行數(shù)據(jù)是未提交的數(shù)據(jù)，innodb會阻止該事務(wù)讀取該行數(shù)據(jù)，從而避免了臟讀的問題。

不可重復(fù)讀的解決

innodb通過mvcc解決不可重復(fù)讀的問題，在RR數(shù)據(jù)庫隔離級別下，當(dāng)我們使用快照進(jìn)行數(shù)據(jù)讀取的時(shí)候，只會在第一次讀取的時(shí)候生成一個(gè)ReadView，后續(xù)所有快照讀都是使用同一個(gè)快照，所以就不會發(fā)生不可重復(fù)讀的問題了。

可重復(fù)讀模式下舉個(gè)栗子：事務(wù)隔離級別為RR：

創(chuàng)建個(gè)測試表，并插入一條數(shù)據(jù)（1,1,1）

create table table1(
    id int(11) not null,
? ? a varchar(50) default null,
? ? b varchar(50) default null,
? ? primary key(id)
)ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

分別開啟兩個(gè)事務(wù)測試：

幻讀的解決

innodb的mvcc和間隙鎖在一定程度上避免了幻讀的發(fā)生，但是沒有辦法完全避免，當(dāng)一個(gè)事務(wù)讀的時(shí)候會導(dǎo)致幻讀的發(fā)生。

幻讀的case：

創(chuàng)建一個(gè)用戶表

create table user(
    id int not null,
    name varchar(50),
    age int,
    primary key(id)
);

插入幾條數(shù)據(jù)

insert into user values(1,'張三',10),(2,'李四',20),(3,'王二',30);

分別開啟兩個(gè)事務(wù)測試：

MVCC實(shí)現(xiàn)

每條記錄在更新的時(shí)候都會同時(shí)記錄一條回滾操作。同一條記錄在系統(tǒng)中可以存在多個(gè)版本，這就是數(shù)據(jù)庫的多版本并發(fā)控制（MVCC）。

MySQL中每條記錄，除了我們自定義的字段之外，還有數(shù)據(jù)庫隱藏定義的三個(gè)字段：

字段	描述
DB_TRX_ID	6字節(jié)，最近修改事務(wù)id，記錄創(chuàng)建這套記錄后者最后一次修改該記錄的事務(wù)id
DB_ROLL_PTR	7字節(jié)，回滾指針，指向這條記錄的上一個(gè)版本，用于配合undolog
DB_ROW_ID	6字節(jié)，隱藏的主鍵，如果數(shù)據(jù)表沒有主鍵，那么innodb會生成一個(gè)6字節(jié)的row_id

在 MySQL 中，實(shí)際上每條記錄在更新的時(shí)候都會同時(shí)記錄一條回滾操作。記錄上的最新值，通過回滾操作，都可以得到前一個(gè)狀態(tài)的值。

InnoDB 并不會真正地去開辟空間存儲多個(gè)版本的行記錄，只是借助 undo log 記錄每次寫操作的反向操作。所以B+ 索引樹上對應(yīng)的記錄只會有一個(gè)最新版本，InnoDB 可以根據(jù) undo log 得到數(shù)據(jù)的歷史版本，從而實(shí)現(xiàn)多版本控制。

Read View

什么是Read View，說白了Read View就是事務(wù)進(jìn)行快照讀操作的時(shí)候生產(chǎn)的讀視圖(Read View)，在該事務(wù)執(zhí)行的快照讀的那一刻，會生成數(shù)據(jù)庫系統(tǒng)當(dāng)前的一個(gè)快照，記錄并維護(hù)系統(tǒng)當(dāng)前活躍事務(wù)的ID(當(dāng)每個(gè)事務(wù)開啟時(shí)，都會被分配一個(gè)ID, 這個(gè)ID是遞增的，所以最新的事務(wù)，ID值越大)

所以我們知道 Read View主要是用來做可見性判斷的, 即當(dāng)我們某個(gè)事務(wù)執(zhí)行快照讀的時(shí)候，對該記錄創(chuàng)建一個(gè)Read View讀視圖，把它比作條件用來判斷當(dāng)前事務(wù)能夠看到哪個(gè)版本的數(shù)據(jù)，即可能是當(dāng)前最新的數(shù)據(jù)，也有可能是該行記錄的undo log里面的某個(gè)版本的數(shù)據(jù)。

Read View遵循一個(gè)可見性算法，主要是將要被修改的數(shù)據(jù)的最新記錄中的DB_TRX_ID（即當(dāng)前事務(wù)ID）取出來，與系統(tǒng)當(dāng)前其他活躍事務(wù)的ID去對比（由Read View維護(hù)），如果DB_TRX_ID跟Read View的屬性做了某些比較，不符合可見性，那就通過DB_ROLL_PTR回滾指針去取出Undo Log中的DB_TRX_ID再比較，即遍歷鏈表的DB_TRX_ID（從鏈?zhǔn)椎芥溛?，即從最近的一次修改查起），直到找到滿足特定條件的DB_TRX_ID, 那么這個(gè)DB_TRX_ID所在的舊記錄就是當(dāng)前事務(wù)能看見的最新老版本

假設(shè)一個(gè)值從 1 被按順序改成了 2、3、4，在回滾日志里面就會有類似下面的記錄。

當(dāng)前值是 4，但是在查詢這條記錄的時(shí)候，不同時(shí)刻啟動(dòng)的事務(wù)會有不同的 read-view。如圖中看到的，在視圖 A、B、C 里面，這一個(gè)記錄的值分別是 1、2、4，同一條記錄在系統(tǒng)中可以存在多個(gè)版本，就是數(shù)據(jù)庫的多版本并發(fā)控制（MVCC）。對于 read-view A，要得到 1，就必須將當(dāng)前值依次執(zhí)行圖中所有的回滾操作得到。同時(shí)你會發(fā)現(xiàn)，即使現(xiàn)在有另外一個(gè)事務(wù)正在將 4 改成 5，這個(gè)事務(wù)跟 read-view A、B、C 對應(yīng)的事務(wù)是不會沖突的。你一定會問，回滾日志總不能一直保留吧，什么時(shí)候刪除呢？答案是，在不需要的時(shí)候才刪除。也就是說，系統(tǒng)會判斷，當(dāng)沒有事務(wù)再需要用到這些回滾日志時(shí)，回滾日志會被刪除。什么時(shí)候才不需要了呢？就是當(dāng)系統(tǒng)里沒有比這個(gè)回滾日志更早的 read-view 的時(shí)候。