一.基本概念

事務(wù)是指滿足ACID特性的的一組操作，可以通過Commit提交事務(wù)，也可以也可以通過Rollback進(jìn)行回滾。會(huì)存在中間態(tài)和一致性狀態(tài)（也是真正在數(shù)據(jù)庫表中存在的狀態(tài)）

二.ACID

Atomicity【原子性】：事務(wù)被視為不可分割的最小單元，事務(wù)的所有操作要么全部提交成功，要么全部失敗回滾?；貪L可以用回滾日志（undo Log）來實(shí)現(xiàn)，回滾日志記錄著事務(wù)所執(zhí)行的修改操作，在回滾時(shí)反向執(zhí)行這些修改操作即可

undoLog：為了滿足事務(wù)的原子性，在操作任何數(shù)據(jù)之前，首先將數(shù)據(jù)備份到Undo Log，然后進(jìn)行數(shù)據(jù)的修改。如果出現(xiàn)了錯(cuò)誤或者用戶執(zhí)行了ROLLBACK語句，系統(tǒng)可以利用Undo Log中的備份將數(shù)據(jù)恢復(fù)到事務(wù)開始之前的狀態(tài)。與redo log不同的是，磁盤上不存在單獨(dú)的undo log文件，它存放在數(shù)據(jù)庫內(nèi)部的一個(gè)特殊段(segment)中，這稱為undo段(undo segment)，undo段位于共享表空間內(nèi)。Innodb為每行記錄都實(shí)現(xiàn)了三個(gè)隱藏字段：6字節(jié)的事務(wù)ID（DB_TRX_ID）7字節(jié)的回滾指針（DB_ROLL_PTR）隱藏的ID

Consistency【一致性】：數(shù)據(jù)庫在事務(wù)執(zhí)行前后都保持一致性狀態(tài)，在一致性狀態(tài)下，所有事務(wù)對同一個(gè)數(shù)據(jù)的讀取結(jié)果都是相同的

Isolation【隔離性】：一個(gè)事務(wù)所做的修改在最終提交前，對其他事務(wù)是不可見的

Durability【持久性】：一旦事務(wù)提交，則其所做的修改將會(huì)永遠(yuǎn)保存到數(shù)據(jù)庫中，即使系統(tǒng)發(fā)生崩潰，事務(wù)執(zhí)行的結(jié)果也不能丟失。系統(tǒng)發(fā)生崩潰可以用redoLog進(jìn)行恢復(fù)，從而實(shí)現(xiàn)持久性。與undoLog記錄數(shù)據(jù)的邏輯修改不同，redoLog記錄的是數(shù)據(jù)頁的物理修改小結(jié)：
1. 只有滿足一致性，事務(wù)的執(zhí)行結(jié)果才是正確的。
2. 在無并發(fā)的情況下，事務(wù)串行執(zhí)行，隔離性一定能夠滿足。此時(shí)只要能夠滿足原子性，就一定能滿足一致性。
3. 在并發(fā)情況下，多個(gè)事務(wù)并行執(zhí)行，事務(wù)不僅要滿足原子性，還需要滿足隔離性，才能滿足一致性
4. 事務(wù)滿足持久化是為了能夠應(yīng)對系統(tǒng)崩潰的情況

三.AutoCommit

MySQL默認(rèn)采用自動(dòng)提交模式，也就是說，如果不顯示使用start transaction語句來開始一個(gè)事務(wù)，那么每個(gè)操作都會(huì)被當(dāng)做一個(gè)事務(wù)并自動(dòng)提交

四.事務(wù)隔離級(jí)別

未提交讀【read uncommitted】：事務(wù)中的修改，即使沒有提交，對其他事務(wù)也是可見的

提交讀【read committed】：一個(gè)事務(wù)只能讀取已經(jīng)提交的事務(wù)所做的修改，換句話說，一個(gè)事務(wù)所做的修改在提交之前對其他事務(wù)是不可見的

可重復(fù)讀【repeatable read】：保證在同一個(gè)事務(wù)中多次讀取同一數(shù)據(jù)的結(jié)果是一樣的可串行化【serializable】：強(qiáng)制事務(wù)串行執(zhí)行，這樣多個(gè)事務(wù)互不干擾，不會(huì)出現(xiàn)并發(fā)一致性問題，該隔離級(jí)別需要加鎖實(shí)現(xiàn)，因?yàn)橐褂眉渔i機(jī)制保證同一時(shí)間只有一個(gè)事務(wù)執(zhí)行，也就是保證事務(wù)串行執(zhí)行

五.并發(fā)一致性問題

背景

在并發(fā)環(huán)境下，事務(wù)的隔離性很難保證，因此會(huì)出現(xiàn)很多并發(fā)一致性問題

主要場景

丟失修改：丟失修改指一個(gè)事務(wù)更新操作被另外一個(gè)事務(wù)的更新操作替換。例如：T1 和 T2 兩個(gè)事務(wù)都對一個(gè)數(shù)據(jù)進(jìn)行修改，T1 先修改并提交生效，T2 隨后修改，T2 的修改覆蓋了 T1 的修改。
業(yè)務(wù)場景：用戶修改地址有修改地址信息和設(shè)置默認(rèn)地址或者刪除地址，這三個(gè)場景都是調(diào)用的同一個(gè)update語句。提供給用戶更新地址的接口需要支持用戶可設(shè)置默認(rèn)地址，而不能將更新地址信息和設(shè)置默認(rèn)地址分開提供接口，如果分開提供，上層服務(wù)調(diào)用實(shí)際上是一下子調(diào)用兩個(gè)更新接口，這樣很容易會(huì)出現(xiàn)丟失修改的場景。

讀臟數(shù)據(jù)：讀臟數(shù)據(jù)指在不同的事務(wù)下，當(dāng)前事務(wù)可以讀取到另外事務(wù)未提交的數(shù)據(jù)，例如：T1 修改一個(gè)數(shù)據(jù)但未提交，T2 隨后讀取這個(gè)數(shù)據(jù)。如果 T1 撤銷了這次修改，那么 T2 讀取的數(shù)據(jù)是臟數(shù)據(jù)。

不可重復(fù)讀：不可重復(fù)讀指在一個(gè)事務(wù)內(nèi)多次讀取同一數(shù)據(jù)集合，在這一事務(wù)還未結(jié)束前，另一個(gè)事務(wù)也訪問了該同一數(shù)據(jù)集合并做了修改，由于第二個(gè)事務(wù)的修改，第一次事務(wù)的兩次讀取的數(shù)據(jù)可能不一致。例如：T2 讀取一個(gè)數(shù)據(jù)，T1 對該數(shù)據(jù)做了修改。如果 T2 再次讀取這個(gè)數(shù)據(jù)，此時(shí)讀取的結(jié)果和第一次讀取的結(jié)果不同。

幻影讀：幻讀本質(zhì)上也屬于不可重復(fù)讀的情況，T1讀取某個(gè)范圍的數(shù)據(jù)，T2在這個(gè)范圍內(nèi)插入新的數(shù)據(jù)，T1再次讀取這個(gè)范圍的數(shù)據(jù)，此時(shí)讀取的結(jié)果和第一次讀取的結(jié)果不同

小結(jié)：
產(chǎn)生并發(fā)不一致性問題的主要原因是破壞了事務(wù)的隔離性，解決方法是通過并發(fā)控制來保證隔離性。并發(fā)控制可以通過封鎖來實(shí)現(xiàn)，但是封鎖操作需要用戶自己控制，相當(dāng)復(fù)雜。數(shù)據(jù)庫管理系統(tǒng)提供了事務(wù)的隔離級(jí)別，讓用戶以一種更輕松的方式處理并發(fā)一致性問題。

六.鎖

封鎖粒度：

行級(jí)鎖：只封鎖需要修改的那部分?jǐn)?shù)據(jù)或那行，不是封鎖所有資源，發(fā)生鎖爭用的可能小，系統(tǒng)并發(fā)程度高

表級(jí)鎖：封鎖整個(gè)表，鎖定數(shù)據(jù)量太大，發(fā)生鎖爭用的概率大大加大，系統(tǒng)并發(fā)性能直線下滑

注意：加鎖就會(huì)消耗資源，鎖的各種操作【包括獲取鎖，釋放鎖，檢查鎖狀態(tài)都會(huì)增加系統(tǒng)開銷，因此封鎖的粒度越小，系統(tǒng)開銷越大】，在選擇封鎖粒度時(shí)，需要在鎖開銷和并發(fā)程度之間做一個(gè)權(quán)衡

封鎖類型

讀寫鎖

互斥鎖，簡寫為X鎖，又稱寫鎖。
一個(gè)事務(wù)對數(shù)據(jù)對象 A 加了 X 鎖，就可以對 A 進(jìn)行讀取和更新。加鎖期間其它事務(wù)不能對 A 加任何鎖。

共享鎖，簡寫為S鎖，又稱讀鎖。
一個(gè)事務(wù)對數(shù)據(jù)對象 A 加了 S 鎖，可以對 A 進(jìn)行讀取操作，但是不能進(jìn)行更新操作。加鎖期間其它事務(wù)能對 A 加 S 鎖，但是不能加 X 鎖。

意向鎖

主要是表鎖，但是不會(huì)真的鎖

在存在行級(jí)鎖和表級(jí)鎖的情況下，事務(wù) T 想要對表 A 加 X 鎖，就需要先檢測是否有其它事務(wù)對表 A 或者表 A 中的任意一行加了鎖，那么就需要對表 A 的每一行都檢測一次，這是非常耗時(shí)的。
意向鎖在原來的 X/S 鎖之上引入了 IX/IS，IX/IS 都是表鎖，用來表示一個(gè)事務(wù)想要在表中的某個(gè)數(shù)據(jù)行上加 X 鎖或 S 鎖。
有以下兩個(gè)規(guī)定：
一個(gè)事務(wù)在獲得某個(gè)數(shù)據(jù)行對象的 S 鎖之前，必須先獲得表的 IS 鎖或者更強(qiáng)的鎖；
一個(gè)事務(wù)在獲得某個(gè)數(shù)據(jù)行對象的 X 鎖之前，必須先獲得表的 IX 鎖。
通過引入意向鎖，事務(wù) T 想要對表 A 加 X 鎖，只需要先檢測是否有其它事務(wù)對表 A 加了 X/IX/S/IS 鎖，如果加了就表示有其它事務(wù)正在使用這個(gè)表或者表中某一行的鎖，因此事務(wù) T 加 X 鎖失敗。

任意 IS/IX 鎖之間都是兼容的，因?yàn)樗鼈冎槐硎鞠胍獙Ρ砑渔i，而不是真正加鎖；
這里兼容關(guān)系針對的是表級(jí)鎖，而表級(jí)的 IX 鎖和行級(jí)的 X 鎖兼容，兩個(gè)事務(wù)可以對兩個(gè)數(shù)據(jù)行加 X 鎖。
（事務(wù) T1 想要對數(shù)據(jù)行 R1 加 X 鎖，事務(wù) T2 想要對同一個(gè)表的數(shù)據(jù)行 R2 加 X 鎖，兩個(gè)事務(wù)都需要對該表加 IX 鎖，但是 IX 鎖是兼容的，并且 IX 鎖與行級(jí)的 X 鎖也是兼容的，因此兩個(gè)事務(wù)都能加鎖成功，對同一個(gè)表中的兩個(gè)數(shù)據(jù)行做修改。）

七.MySQL隱式與顯示鎖定

隱式鎖定：MySQL 的 InnoDB 存儲(chǔ)引擎采用兩段鎖協(xié)議，會(huì)根據(jù)隔離級(jí)別在需要的時(shí)候自動(dòng)加鎖，并且所有的鎖都是在同一時(shí)刻被釋放，這被稱為隱式鎖定

兩段鎖協(xié)議:加鎖和解鎖分為兩個(gè)階段進(jìn)行，可串行化調(diào)度是指通過并發(fā)控制，使得并發(fā)執(zhí)行的事務(wù)結(jié)果與某個(gè)串行執(zhí)行的事務(wù)結(jié)果相同，串行執(zhí)行的事務(wù)互不干擾，不會(huì)出現(xiàn)并發(fā)一致性問題

或者使用特定語句進(jìn)行顯示鎖定SELECT ... LOCK In SHARE MODE;（共享鎖）SELECT ... FOR UPDATE;（排他鎖）事務(wù)完成提交自動(dòng)釋放鎖

MySQL三級(jí)封鎖協(xié)議

一級(jí)封鎖協(xié)議：事務(wù)T要修改數(shù)據(jù)A時(shí)必須加X鎖，知道事務(wù)T結(jié)束才釋放鎖可以解決丟失修改問題。這時(shí)候不能同時(shí)有兩個(gè)事務(wù)對同一個(gè)數(shù)據(jù)進(jìn)行修改，那么事務(wù)的修改就不會(huì)被覆蓋

二級(jí)封鎖協(xié)議：在一級(jí)基礎(chǔ)上，要求讀取數(shù)據(jù)A時(shí)必須加S鎖，讀取完馬上釋放S鎖可以解決讀臟數(shù)據(jù)問題。因?yàn)槿绻幸粋€(gè)事務(wù)在對數(shù)據(jù)A進(jìn)行修改，根據(jù)1級(jí)封鎖協(xié)議，會(huì)加X鎖，那么就不能再加S鎖了，也就是不會(huì)讀入臟數(shù)據(jù)

三級(jí)封鎖協(xié)議：在二級(jí)基礎(chǔ)上，要求讀取數(shù)據(jù)時(shí)必須加S鎖，直到事務(wù)結(jié)束了才能釋放S鎖可以解決不可重復(fù)讀的問題，因?yàn)樽xA時(shí)，其他事務(wù)不能對A加X鎖，從而避免了在讀期間數(shù)據(jù)發(fā)生改變

八.InnoDB引擎的鎖實(shí)現(xiàn)

MVCC

多版本并發(fā)控制是MySQL的innoDB存儲(chǔ)引擎實(shí)現(xiàn)隔離級(jí)別的一種具體方式，可用于實(shí)現(xiàn)提交讀和可重復(fù)讀這兩種隔離級(jí)別，而未提交讀隔離級(jí)別總是讀取最新的數(shù)據(jù)行，要求很低，無需使用MVCC

在封鎖一節(jié)中提到，加鎖能解決多個(gè)事務(wù)同時(shí)執(zhí)行時(shí)出現(xiàn)的并發(fā)一致性問題。在實(shí)際場景中讀操作往往多于寫操作，因此又引入了讀寫鎖來避免不必要的加鎖操作，例如讀和讀沒有互斥關(guān)系。讀寫鎖中讀和寫操作仍然是互斥的，而 MVCC 利用了多版本的思想，寫操作更新最新的版本快照，而讀操作去讀舊版本快照，沒有互斥關(guān)系，這一點(diǎn)和 CopyOnWrite 類似。

在 MVCC 中事務(wù)的修改操作（DELETE、INSERT、UPDATE）會(huì)為數(shù)據(jù)行新增一個(gè)版本快照。臟讀和不可重復(fù)讀最根本的原因是事務(wù)讀取到其它事務(wù)未提交的修改。在事務(wù)進(jìn)行讀取操作時(shí)，為了解決臟讀和不可重復(fù)讀問題，MVCC 規(guī)定只能讀取已經(jīng)提交的快照。當(dāng)然一個(gè)事務(wù)可以讀取自身未提交的快照，這不算是臟讀。

系統(tǒng)版本號(hào) SYS_ID：是一個(gè)遞增的數(shù)字，每開始一個(gè)新的事務(wù)，系統(tǒng)版本號(hào)就會(huì)自動(dòng)遞增。

事務(wù)版本號(hào) TRX_ID ：事務(wù)開始時(shí)的系統(tǒng)版本號(hào)。

MVCC的多版本指的是多個(gè)版本的快照，快照存儲(chǔ)在Undo日志中，該日志通過回滾指針ROLL_PTR把一個(gè)數(shù)據(jù)行的所有快照連接起來

INSERT、UPDATE、DELETE 操作會(huì)創(chuàng)建一個(gè)日志，并將事務(wù)版本號(hào) TRX_ID 寫入。DELETE 可以看成是一個(gè)特殊的 UPDATE，還會(huì)額外將 DEL 字段設(shè)置為 1

ReadView

MVCC維護(hù)了一個(gè)ReadView結(jié)構(gòu)，主要包含了當(dāng)前系統(tǒng)未提交的事務(wù)列表，還有該列表的最小值和最大值

在進(jìn)行 SELECT 操作時(shí)，根據(jù)數(shù)據(jù)行快照的 TRX_ID 與 TRX_ID_MIN 和 TRX_ID_MAX 之間的關(guān)系，從而判斷數(shù)據(jù)行快照是否可以使用。

TRX_ID < TRX_ID_MIN，表示該數(shù)據(jù)行快照時(shí)在當(dāng)前所有未提交事務(wù)之前進(jìn)行更改的，因此可以使用。

TRX_ID > TRX_ID_MAX，表示該數(shù)據(jù)行快照是在事務(wù)啟動(dòng)之后被更改的，因此不可使用。

TRX_ID_MIN <= TRX_ID <= TRX_ID_MAX，需要根據(jù)隔離級(jí)別再進(jìn)行判斷

提交讀：如果 TRX_ID 在 TRX_IDs 列表中，表示該數(shù)據(jù)行快照對應(yīng)的事務(wù)還未提交，則該快照不可使用。否則表示已經(jīng)提交，可以使用。

可重復(fù)讀：都不可以使用。因?yàn)槿绻梢允褂玫脑?，那么其它事?wù)也可以讀到這個(gè)數(shù)據(jù)行快照并進(jìn)行修改，那么當(dāng)前事務(wù)再去讀這個(gè)數(shù)據(jù)行得到的值就會(huì)發(fā)生改變，也就是出現(xiàn)了不可重復(fù)讀問題。在數(shù)據(jù)行快照不可使用的情況下，需要沿著 Undo Log 的回滾指針 ROLL_PTR 找到下一個(gè)快照，再進(jìn)行上面的判斷。

快照讀和安全讀

快照讀：MVCC的select操作是快照中的數(shù)據(jù)，不需要進(jìn)行加鎖操作

當(dāng)前讀：MVCC其它會(huì)對數(shù)據(jù)庫進(jìn)行修改的操作就需要進(jìn)行加鎖操作，從而讀取最新的數(shù)據(jù)，可以看到MVCC并不是完全不用加鎖，而只是避免了select的加鎖操作

如果需要select進(jìn)行加鎖，就可以強(qiáng)制指定加鎖操作，如之前提到的共享鎖和排他鎖

Next-Key Locks

概念：Next-Key Locks 是 MySQL 的 InnoDB 存儲(chǔ)引擎的一種鎖實(shí)現(xiàn)。MVCC 不能解決幻影讀問題，Next-Key Locks 就是為了解決這個(gè)問題而存在的。在可重復(fù)讀（REPEATABLE READ）隔離級(jí)別下，使用 MVCC + Next-Key Locks 可以解決幻讀問題。

Record Locks：鎖定一個(gè)記錄上的索引，而不是記錄本身，如果表沒有設(shè)置索引，InnoDB會(huì)自動(dòng)在主鍵上創(chuàng)建隱藏的聚簇索引

Gap Locks：鎖定索引之間的間隙，但是不包含索引本身。例如當(dāng)一個(gè)事務(wù)執(zhí)行以下語句SELECT c FROM t WHERE c BETWEEN 10 and 20 FOR UPDATE;

Next-Key Locks：它是 Record Locks 和 Gap Locks 的結(jié)合，不僅鎖定一個(gè)記錄上的索引，也鎖定索引之間的間隙。它鎖定一個(gè)前開后閉區(qū)間，例如一個(gè)索引包含以下值：10, 11, 13, and 20，那么就需要鎖定以下區(qū)間：(-∞, 10](10, 11](11, 13](13, 20](20, +∞)

九.總結(jié)

上述理論較多，但是也是這些理論支撐整個(gè)研發(fā)過程，遇到多種業(yè)務(wù)場景時(shí)，需要根據(jù)數(shù)據(jù)庫的隔離級(jí)別判斷事務(wù)會(huì)不會(huì)出現(xiàn)死鎖，數(shù)據(jù)不一致等等理論性問題。MySQL最厲害的地方也是在RR【可重復(fù)讀】級(jí)別下避免了幻讀，即兼顧性能又保證數(shù)據(jù)安全。
在開發(fā)微服務(wù)或者分布使項(xiàng)目時(shí)。盡量將事務(wù)寫的簡單些，讓事務(wù)不會(huì)長時(shí)間鎖住對應(yīng)的行。這樣也是保證了數(shù)據(jù)的一致性

到此這篇關(guān)于MySQL數(shù)據(jù)庫事務(wù)與鎖深入分析的文章就介紹到這了,更多相關(guān)MySQL數(shù)據(jù)庫事務(wù)與鎖內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！