Mysql核心框架知識

Mysql核心框架

本文旨在梳理和理解 MySQL 的一些核心知識點，并結合常見面試題進行思考和總結。這些內容主要來源于我的個人學習與理解。

1. 事務

概念

事務指的是滿足 ACID 特性的一組操作，可以通過 Commit 提交一個事務，也可以使用 Rollback 進行回滾。

那抹什么是ACID呢？

ACID

原子性（Atomicity）

? 事務被視為不可分割的最小單元，事務的所有操作要么全部提交成功，要么全部失敗回滾。

? 回滾可以用回滾日志（Undo Log）來實現，回滾日志記錄著事務所執行的修改操作，在回滾時反向執行這些修改操作即可。

一致性（Consistency）

? 數據庫在事務執行前后都保持一致性狀態。在一致性狀態下，所有事務對同一個數據的讀取結果都是相同的。

? 我個人理解就是這個執行結果要合理，不能我轉了你500，你拿到了1000這種狀態。

隔離性（Isolation）

? 一個事務所做的修改在最終提交以前，對其它事務是不可見的。

持久性（Durability）

? 一旦事務提交，則其所做的修改將會永遠保存到數據庫中。即使系統發生崩潰，事務執行的結果也不能丟失。

? 系統發生崩潰可以用重做日志（·Redo Log·）進行恢復，從而實現持久性。與回滾日志記錄數據的邏輯修改不同，重做日志記錄的是數據頁的物理修改。

舉個例子:

例如，A向B轉賬500元，這個操作要么都成功，要么都失敗，體現了原子性。轉賬過程中數據要保持一致，A扣除了500元，B必須增加500元。隔離性體現在A向B轉賬時，不受其他事務干擾。持久性體現在事務提交后，數據要被持久化存儲。

事務的 ACID 特性概念簡單，但不是很好理解，主要是因為這幾個特性不是一種平級關系：

只有滿足一致性，事務的執行結果才是正確的。
在無并發的情況下，事務串行執行，隔離性一定能夠滿足。此時只要能滿足原子性，就一定能滿足一致性。
在并發的情況下，多個事務并行執行，事務不僅要滿足原子性，還需要滿足隔離性，才能滿足一致性。
事務滿足持久化是為了能應對系統崩潰的情況。

在這里插入圖片描述

原子性和隔離性直接保證一致性，簡介保證執行結果的正確。而一致性是覺得執行結果正確的直接因素。

持久性用于應對系統的崩潰，提高數據庫的高可用性和魯棒性。

2. 并發一致性問題

注意w為write操作,r為read操作

丟失修改

T1	T2
w a=10
	w a=20
r a=20
	r a=20

可以看到我們的T1線程和T2線程并發執行的時候T1丟失了原來a=10的操作痕跡，T2后提交覆蓋了T1的提交，似乎T1沒有執行w a=10的操作一樣，這就是"丟失修改"。

讀臟數據

T1	T2
r a=10
w a=20
	r a=20
rollback

T1,T2并發執行在前面都沒問題，可是當T1rollback操作后數據庫里面的值又變回了10，此時T2拿到并不是數據庫真實的數據，如果拿著這個數據執行支付操作可想而知會給我們的系統造成多大的損失。

不可重復讀

T1	T2
	r a=10
w a=20
	r a=20

其實不可重復讀很好理解，就是在同一個事務中我進行兩次讀取操作結果獲得值不相同，也可能會對我們的系統造成很大的困擾。

幻影讀(幻讀)

T1	T2
count(user_id) 1
	delete(user_object)
count(user_id) 0

幻讀的出現場景主要在聚合函數統計時候出現的概率比較大一些。一個事務下的兩次聚合操作竟然不相同，如果是在秒殺場景里面，可能就造成了超買超賣問題。

3. 封鎖

鎖的粒度

MySQL在粒度上分類的話分為行級鎖、表級鎖、頁面鎖

表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖沖突的概率最高，并發度最低。
行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖沖突的概率最低，并發度也最高。
頁面鎖：開銷和加鎖時間界于表鎖和行鎖之間；會出現死鎖；鎖定粒度界于表鎖和行鎖之間，并發度一般

從性能上看的話，鎖的粒度越細，能夠并發的線程數量就越多，性能就越高。反之則性能越低。所以從這個層面上考慮的行級鎖的性能是高于標記鎖的。

三種常用引擎的支持情況

InnoDB	MyISAM	MEMORY
行級鎖和表級鎖	支持表級鎖	支持標記鎖

從這也可以看出來InnoDB在鎖的性能上是高于其他兩個存儲引擎的。

表級鎖

基本的兩大類表鎖

ＭySQL的表鎖有兩種模式：表共享讀鎖（Table Read Lock）和表獨占寫鎖（Table Write Lock）

表共享讀鎖（Table Read Lock）：不會阻塞其他用戶對同一表的讀請求，但會阻塞對同一表的寫請求；
表獨占寫鎖（Table Write Lock）：會阻塞其他用戶對同一表的讀和寫操作；

當然有些存儲引擎還支持意向鎖，如我們大名鼎鼎的InnoDB。

是否阻塞	讀鎖	寫鎖
讀鎖	Y	N
寫鎖	N	N

tip：讀讀兼容，讀寫阻塞，寫寫阻塞

行級鎖

基本的兩大類行鎖

共享鎖（S 鎖，Shared Lock）
- 允許多個事務同時讀一行，但不能寫。
排他鎖（X 鎖，Exclusive Lock）
- 一個事務獲取排他鎖后，別人既不能讀也不能寫（讀是指加鎖的讀）。
- 常見在 UPDATE、DELETE、INSERT 操作里會自動加。

InnoDB 特有的“變種”行鎖

為了處理復雜的并發場景，InnoDB 在基本 S/X 鎖上又擴展出幾種：

記錄鎖（Record Lock）
- 最常見的行鎖，就是鎖住某一條索引記錄。
- 前提是查詢必須用到索引，否則可能升級成表鎖。
間隙鎖（Gap Lock）
- 鎖住某個范圍的“間隙”，而不是已有的行。
- 用來防止“幻讀”（別人插入新行導致范圍查詢結果變了）。
- 例如：
```
SELECT * FROM user WHERE age BETWEEN 20 AND 30 FOR UPDATE;
```
  FOR UPDATE → 給匹配行加排他鎖。
  
  BETWEEN 20 AND 30 → 鎖住這個范圍的記錄。
臨鍵鎖（Next-Key Lock）
- 記錄鎖 + 間隙鎖的組合，鎖住“某一條記錄及其前面的間隙”。
- 這是 InnoDB 在 可重復讀（RR） 隔離級別下的默認模式，主要就是為了防止幻讀。

InnoDB默認情況下使用的就是行鎖，如果要表鎖的話必須顯式加鎖。

InnoDB與MyISAM的最大不同有兩點：

一是支持事務（TRANSACTION）；
二是采用了行級鎖。

行鎖定是對索引記錄的鎖定。

SELECT c1 FROM t WHERE c1 = 10 FOR UPDATE;

防止任何其他事務插入，更新或刪除t.c1值為10的行。

MySQL 的 UPDATE 在并發情況下，如果是 InnoDB 引擎，會通過行級排他鎖避免同一行被多個事務同時修改。這也是Mysql層面上的解決超買超賣的一種手段捏。

行鎖升級為表鎖

行鎖也有可能升級成表鎖，具體的情況：

不適用索引的情況下加鎖
使用普通索引的情況下加鎖（tips:普通索引不限制值單純建立b+樹來加快查詢速度，隨便插,咱普遍說的索引一般是主鍵索引和唯一索引有非重復的需求)
范圍性查詢

總結行鎖是建立在索引的基礎上的，普通索引的數據重復率過高或導致索引失效，行鎖升級為表鎖

封鎖的類型

讀寫鎖

互斥鎖（Exclusive），簡寫為 X 鎖，又稱寫鎖。
共享鎖（Shared），簡寫為 S 鎖，又稱讀鎖。

有以下兩個規定：

一個事務對數據對象 A 加了 X 鎖，就可以對 A 進行讀取和更新。加鎖期間其它事務不能對 A 加任何鎖。
一個事務對數據對象 A 加了 S 鎖，可以對 A 進行讀取操作，但是不能進行更新操作。加鎖期間其它事務能對 A 加 S 鎖，但是不能加 X 鎖。

是否阻塞	讀鎖	寫鎖
讀鎖	Y	N
寫鎖	N	N

也就是上面行級鎖里面的規定

意向鎖

使用意向鎖（Intention Locks）可以更容易地支持多粒度封鎖。

在存在行級鎖和表級鎖的情況下，事務 T 想要對表 A 加 X 鎖，就需要先檢測是否有其它事務對表 A 或者表 A 中的任意一行加了鎖，那么就需要對表 A 的每一行都檢測一次，這是非常耗時的。

意向鎖在原來的 X/S 鎖之上引入了 IX/IS，IX/IS 都是表鎖，用來表示一個事務想要在表中的某個數據行上加 X 鎖或 S 鎖。有以下兩個規定：

一個事務在獲得某個數據行對象的 S 鎖之前，必須先獲得表的 IS 鎖或者更強的鎖；
一個事務在獲得某個數據行對象的 X 鎖之前，必須先獲得表的 IX 鎖。

通過引入意向鎖，事務 T 想要對表 A 加 X 鎖，只需要先檢測是否有其它事務對表 A 加了 X/IX/S/IS 鎖，如果加了就表示有其它事務正在使用這個表或者表中某一行的鎖，因此事務 T 加 X 鎖失敗。

4. 封鎖協議

一共有三層封鎖協議

一級封鎖協議

事務 T 要修改數據 A 時必須加 X 鎖，直到 T 結束才釋放鎖。

T1	T2
lock-x a
w a=10	lock-x a
commit
unlock-x a
	get lock-x
	w a=20
	commit
	unlock-x a

可以看到，因為每次只有一個事務可以進行寫操作，所以我們的事務修改就不會被覆蓋

二級封鎖協議

在一級的基礎上，要求讀取數據 A 時必須加 S 鎖，讀取完馬上釋放 S 鎖。

T1	T2
lock-x a
r a=10
w a=20	lock-s a
rollback
unlock-x a
	get lock-s
	r a=10
	unlock-s a

可以解決讀臟數據問題，因為如果一個事務在對數據 A 進行修改，根據 1 級封鎖協議，會加 X 鎖，那么就不能再加 S 鎖了，也就是不會讀入數據,用的讀寫阻塞來解決

三級封鎖協議

在二級的基礎上，要求讀取數據 A 時必須加 S 鎖，直到事務結束了才能釋放 S 鎖。

T1	T2
lock-x a
r a=10
r a=10	lock-x a
rollback
unlock-x a
	get lock-x
	w a=20
	commit
	unlock-x a

可以解決不可重復讀的問題，因為讀 A 時，其它事務不能對 A 加 X 鎖，從而避免了在讀的期間數據發生改變。

兩段鎖協議

加鎖和解鎖分為兩個階段進行。

可串行化調度是指，通過并發控制，使得并發執行的事務結果與某個串行執行的事務結果相同。串行執行的事務互不干擾，不會出現并發一致性問題。

事務遵循兩段鎖協議是保證可串行化調度的充分條件。例如以下操作滿足兩段鎖協議，它是可串行化調度。

lock-x(A)...lock-s(B)...lock-s(C)...unlock(A)...unlock(C)...unlock(B)

但不是必要條件，例如以下操作不滿足兩段鎖協議，但它還是可串行化調度。

lock-x(A)...unlock(A)...lock-s(B)...unlock(B)...lock-s(C)...unlock(C)

MySQL 的 InnoDB 存儲引擎采用兩段鎖協議，會根據隔離級別在需要的時候自動加鎖，并且所有的鎖都是在同一時刻被釋放，這被稱為隱式鎖定。

InnoDB 也可以使用特定的語句進行顯示鎖定：

SELECT ... LOCK In SHARE MODE; #加讀鎖
SELECT ... FOR UPDATE;#加排他鎖

5.隔離級別

未提交讀（READ UNCOMMITTED）

事務中的修改，即使沒有提交，對其它事務也是可見的。

提交讀（READ COMMITTED）

一個事務只能讀取已經提交的事務所做的修改。換句話說，一個事務所做的修改在提交之前對其它事務是不可見的。

因為在一個事務提交前的數據是對其他事務不可見的，所以在數據沒有確定存入數據庫前是不會被其他事務看見的，因此解決了數據被讀到是修改后的值，但是另一個事務rollback修改，導致事務中讀取到的數據與數據庫中的數據不一致問題。即為解決了臟讀問題。

可重復讀（REPEATABLE READ）

保證在同一個事務中多次讀取同一數據的結果是一樣的。

可串行化（SERIALIZABLE）

強制事務串行執行，這樣多個事務互不干擾，不會出現并發一致性問題。

該隔離級別需要加鎖實現，因為要使用加鎖機制保證同一時間只有一個事務執行，也就是保證事務串行執行。

隔離級別能解決的并發一致性問題

	臟讀	不可重復讀	幻影讀
未提交讀	×	×	×
提交讀	√	×	×
可重復度	√	√	×
可串行化	√	√	√

6. MVCC

多版本并發控制（Multi-Version Concurrency Control, MVCC）是 MySQL 的 InnoDB 存儲引擎實現隔離級別的一種具體方式，用于實現提交讀和可重復讀這兩種隔離級別。而未提交讀隔離級別總是讀取最新的數據行，要求很低，無需使用 MVCC。可串行化隔離級別需要對所有讀取的行都加鎖，單純使用 MVCC 無法實現。

基本思想

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

在 MVCC 中事務的修改操作（DELETE、INSERT、UPDATE）會為數據行新增一個版本快照。

臟讀和不可重復讀最根本的原因是事務讀取到其它事務未提交的修改。在事務進行讀取操作時，為了解決臟讀和不可重復讀問題，MVCC 規定只能讀取已經提交的快照。當然一個事務可以讀取自身未提交的快照，這不算是臟讀。因為沒有使用 START TRANSACTION 將上面的操作當成一個事務來執行，根據 MySQL 的 AUTOCOMMIT 機制，每個操作都會被當成一個事務來執行，所以上面的操作總共涉及到三個事務。快照中除了記錄事務版本號 TRX_ID 和操作之外，還記錄了一個 bit 的 DEL 字段，用于標記是否被刪除。

Undo 日志

MVCC 的多版本指的是多個版本的快照，快照存儲在 Undo 日志中，該日志通過回滾指針 ROLL_PTR 把一個數據行的所有快照連接起來。

在這里插入圖片描述

例如在 MySQL 創建一個表 t，包含主鍵 id 和一個字段 x。我們先插入一個數據行，然后對該數據行執行兩次更新操作。

INSERT INTO t(id, x) VALUES(1, "a");
UPDATE t SET x="b" WHERE id=1;
UPDATE t SET x="c" WHERE id=1;

因為沒有使用 START TRANSACTION 將上面的操作當成一個事務來執行，根據 MySQL 的 AUTOCOMMIT 機制，每個操作都會被當成一個事務來執行，所以上面的操作總共涉及到三個事務。快照中除了記錄事務版本號 TRX_ID 和操作之外，還記錄了一個 bit 的 DEL 字段，用于標記是否被刪除。

在這里插入圖片描述

INSERT、UPDATE、DELETE 操作會創建一個日志，并將事務版本號 TRX_ID 寫入。DELETE 可以看成是一個特殊的 UPDATE，還會額外將 DEL 字段設置為 1。

ReadView

MVCC 維護了一個 ReadView 結構，主要包含了當前系統未提交的事務列表 TRX_IDs {TRX_ID_1, TRX_ID_2, …}，還有該列表的最小值 TRX_ID_MIN 和 TRX_ID_MAX。

在這里插入圖片描述

在進行 SELECT 操作時，根據數據行快照的 TRX_ID 與 TRX_ID_MIN 和 TRX_ID_MAX 之間的關系，從而判斷數據行快照是否可以使用：

TRX_ID < TRX_ID_MIN，表示該數據行快照時在當前所有未提交事務之前進行更改的，因此可以使用。
TRX_ID > TRX_ID_MAX，表示該數據行快照是在事務啟動之后被更改的，因此不可使用。
TRX_ID_MIN <= TRX_ID <= TRX_ID_MAX，需要根據隔離級別再進行判斷：
- 提交讀：該隔離界別下每一次查詢都要進行一次快照讀(readView)操作，如果 TRX_ID 在 TRX_IDs 列表中，表示該數據行快照對應的事務還未提交，則該快照不可使用。否則表示已經提交，可以使用。
- 可重復讀：**該隔離界別下事務開始的時候進行一次快照讀操作(readView)而且只進行這一次，**如果 TRX_ID 在 TRX_IDs 列表中就不能使用。因為如果可以使用的話，那么其它事務也可以讀到這個數據行快照并進行修改，那么當前事務再去讀這個數據行得到的值就會發生改變，也就是出現了不可重復讀問題。

在數據行快照不可使用的情況下，需要沿著 Undo Log 的回滾指針 ROLL_PTR 找到下一個快照，再進行上面的判斷。