交易與 MVCC：隔離等級的真實代價

ACID 四個字母裡，A（原子性）、D（持久性）靠 redo/undo log 就能解決，C（一致性）是結果。真正難的是 I —— Isolation（隔離性），因為它要處理的是「很多人同時動同一筆資料」。

教科書會給你三個名詞的定義，但定義背了也用不出來。直接看它們長什麼樣：

1. 髒讀（Dirty Read）—— 讀到「還沒提交」的資料

交易 A：UPDATE account SET balance = 700 WHERE id = 1;  （還沒 COMMIT）
交易 B：SELECT balance FROM account WHERE id = 1;  →  讀到 700
交易 A：ROLLBACK;   ← 回滾了！

結果：B 拿到一個「從來沒有真正存在過」的值。

2. 不可重複讀（Non-Repeatable Read）—— 同一筆資料，前後讀到不同值

交易 A：SELECT balance WHERE id = 1;  →  1000
交易 B：UPDATE balance = 700 WHERE id = 1;  COMMIT;
交易 A：SELECT balance WHERE id = 1;  →  700   ← 同一個交易裡變了

針對的是 UPDATE：同一列的內容變了。

3. 幻讀（Phantom Read）—— 同一個範圍，前後讀到不同「筆數」

交易 A：SELECT COUNT(*) WHERE age > 20;  →  10 筆
交易 B：INSERT INTO users (age) VALUES (25);  COMMIT;
交易 A：SELECT COUNT(*) WHERE age > 20;  →  11 筆  ← 多出一筆「幻影」

針對的是 INSERT / DELETE：列數變了。

四種隔離等級就是在選「允許哪幾種」

• READ UNCOMMITTED：三種都可能發生（幾乎沒人用）
• READ COMMITTED（RC）：擋掉髒讀。PostgreSQL、Oracle、SQL Server 的預設
• REPEATABLE READ（RR）：再擋掉不可重複讀。MySQL 的預設
• SERIALIZABLE：全部擋掉，代價是幾乎完全序列化

最直覺的隔離做法是加鎖：我在讀的時候，不准你改。

交易 A：SELECT ... （加讀鎖，鎖住整個交易期間）
交易 B：UPDATE ... （被擋住，等 A 提交）

這確實正確，而且就是 SERIALIZABLE 的做法。問題在代價。

代價一：讀寫互相阻塞

一個報表查詢跑 30 秒，這 30 秒內所有想改到那些列的交易全部卡住。在一個讀多寫多的系統裡，吞吐量會直接崩掉。

代價二：讀取本來是最安全的操作

兩個人同時「讀」同一筆資料，彼此完全沒有影響。但為了防範「可能有人來改」，就讓所有讀取都付出加鎖的成本——這是拿 99% 的正常情況去遷就 1% 的衝突。

MVCC 的思路：不要擋，改成「給你看舊的」

與其阻止 B 修改，不如讓 A 繼續看到修改前的那個版本。既然 A 想要的是「整個交易期間看到一致的資料」，那給它一份「交易開始那一刻的快照」就好了。

• B 的修改照常進行，不用等 A
• A 讀到的是舊版本，不用加鎖
• 兩邊都不用停下來

接下來三張卡就是在講：這些「歷史版本」存在哪裡、怎麼判斷該給你看哪一個。

MVCC 不是一個演算法，是三個零件配合出來的效果。

零件一：每一列都有兩個你看不到的隱藏欄位

• DB_TRX_ID（6 bytes）：最後一次修改這一列的交易 ID。交易 ID 是遞增的，所以它同時代表「新舊」。
• DB_ROLL_PTR（7 bytes）：回滾指標，指向 undo log 裡的上一個版本。

（上一章提過的 row_id 是第三個隱藏欄位，只有在完全沒主鍵時才出現。）

零件二：undo log 串成「版本鏈」

每次 UPDATE，InnoDB 不是就地覆蓋，而是：把舊值寫進 undo log，然後讓新資料的 DB_ROLL_PTR 指向它。

目前的資料列（聚簇索引裡）
  balance = 700 , DB_TRX_ID = 102 , DB_ROLL_PTR ─┐
                                                 ↓
  undo log:  balance = 1000 , DB_TRX_ID = 98 , DB_ROLL_PTR ─┐
                                                            ↓
             balance = 1500 , DB_TRX_ID = 85 , DB_ROLL_PTR ─→ NULL

零件三：Read View —— 決定你能看到哪個版本

當你執行一個快照讀（普通的 SELECT）時，InnoDB 會產生一個 Read View，裡面記著「產生這一刻，系統上有哪些交易還沒提交」。它包含四個欄位：

• m_ids：目前還活躍（未提交）的交易 ID 清單
• min_trx_id：m_ids 裡最小的那個
• max_trx_id：下一個要分配的交易 ID（注意：不是目前最大的）
• creator_trx_id：產生這個 Read View 的交易自己的 ID

有了它，就能沿著版本鏈由新往舊走，找到第一個「你有資格看到」的版本。判斷規則在下一張卡。

拿到一個版本的 DB_TRX_ID（記作 trx_id），依序做三個判斷：

判斷一：trx_id == creator_trx_id？

→ 可見。這是我自己改的，我當然看得到自己的修改。

判斷二：trx_id < min_trx_id？

→ 可見。這個交易在我建立 Read View 之前就已經提交了（因為它比所有活躍交易都舊）。

判斷三：trx_id >= max_trx_id？

→ 不可見。這個交易是在我建立 Read View 之後才開始的，它做的事我不該看到。

判斷四：落在中間（min <= trx_id < max）

→ 看它在不在 m_ids 裡：

• 在 → 不可見（我建立快照時它還沒提交）
• 不在 → 可見（我建立快照時它已經提交了）

不可見的話怎麼辦

沿著 DB_ROLL_PTR 往 undo log 走一格，拿到更舊的版本，再判斷一次。一直往舊的方向走，直到找到可見的版本為止。

目前版本 trx_id=102  → 不可見（在 m_ids 裡）
  ↓ 沿 DB_ROLL_PTR
舊版本   trx_id=98   → 可見（98 < min_trx_id）
  ↓
★ 回傳這個版本的資料

前面鋪了那麼多零件，就是為了這一句：

READ COMMITTED：每一次 SELECT 都建立新的 Read View

交易 A 開始
  SELECT ...  → 建立 Read View #1  → 讀到 1000
               （交易 B 改成 700 並提交）
  SELECT ...  → 建立 Read View #2  → 讀到 700   ← 值變了

因為每次都重新拍快照，所以看得到別人剛提交的東西——這正是「不可重複讀」的成因，也正是「已提交讀」這個名字的意思。

REPEATABLE READ：只在第一次 SELECT 建立，整個交易重複使用

交易 A 開始
  SELECT ...  → 建立 Read View（就這一次）  → 讀到 1000
               （交易 B 改成 700 並提交）
  SELECT ...  → 沿用同一個 Read View        → 還是 1000  ← 值不變

快照凍結在第一次讀取的那一刻，所以整個交易期間看到的世界是一致的。

順帶解掉一個常見誤解

很多人以為 RR 的快照是「交易 BEGIN 的那一刻」建立的。不是——是第一次執行快照讀的時候才建立。所以：

BEGIN;
-- （這裡什麼都還沒讀，別人怎麼改都無所謂）
SELECT ...   ← 快照在這一刻才凍結

如果需要在 BEGIN 當下就凍結，要明確寫 START TRANSACTION WITH CONSISTENT SNAPSHOT。

MVCC 只作用在快照讀上。有一類操作它管不到，叫當前讀。

兩種讀的分界

• 快照讀（Snapshot Read）：普通的 SELECT。走 MVCC，讀歷史版本，不加鎖。
• 當前讀（Current Read）：SELECT ... FOR UPDATE、SELECT ... LOCK IN SHARE MODE、UPDATE、DELETE、INSERT。必須讀最新版本並加鎖——因為你要改它，不可能改在一個舊版本上。

InnoDB 的解法：Next-Key Lock

當前讀時，InnoDB 鎖的不只是那一列，還包含列與列之間的空隙：

• Record Lock：鎖住存在的那一列
• Gap Lock：鎖住兩列之間的區間，防止別人在中間插進來
• Next-Key Lock ＝ Record Lock ＋ Gap Lock，鎖住「這一列＋它前面的空隙」

索引上現有值：10, 20, 30

SELECT * FROM t WHERE id BETWEEN 15 AND 25 FOR UPDATE;
→ 鎖住 20 這一列，也鎖住 (10,20) 與 (20,30) 這兩個空隙
→ 別人想 INSERT id = 18 或 22 都會被擋住

所以再查一次，筆數保證不變 → 幻讀被擋掉了

這是實務上 MVCC 最常見、也最容易被誤診的災難。

因果鏈

1. 一個交易開著沒提交，它的 Read View 一直活著。
2. 只要有任何一個 Read View 可能需要看到某個舊版本，那個舊版本就不能被清理（purge）。
3. 其他交易持續在改資料，undo log 版本鏈一直變長。
4. 其他人的查詢要沿著版本鏈往回走更多格，讀取越來越慢。
5. undo 表空間（ibdata1 或 undo tablespace）持續膨脹，而且不會自己縮回去。

Spring 裡最常見的三種寫法

@Transactional
public void process(Long orderId) {
    Order order = orderRepo.findById(orderId);

    // ❌ 1. 交易裡呼叫外部 HTTP —— 對方慢 30 秒，交易就開 30 秒
    paymentClient.charge(order);

    // ❌ 2. 交易裡做檔案 I/O 或寄信
    mailService.send(order);

    // ❌ 3. 交易裡跑迴圈處理十萬筆
    for (Item item : items) { ... }

    orderRepo.save(order);
}

診斷指令

-- 找出開最久的交易
SELECT trx_id, trx_started,
       TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS 已開啟秒數,
       trx_query
FROM information_schema.innodb_trx
ORDER BY trx_started;

修法

• 交易只包住真正要一起成功或失敗的 DB 操作。外部呼叫、檔案 I/O、寄信全部移到交易外面。
• 要在交易成功後才做的事，用 @TransactionalEventListener(phase = AFTER_COMMIT)。
• 大批次處理切成小批，每批各自一個交易。
• 設定 @Transactional(timeout = 5) 當作保險，讓失控的交易自己死掉而不是拖著大家。

一個常被忽略的事實：MySQL 預設 REPEATABLE READ，但 PostgreSQL、Oracle、SQL Server 都預設 READ COMMITTED。連資料庫廠商都沒有共識，代表這是取捨而不是對錯。

MySQL 為什麼選 RR（歷史因素）

早期 MySQL 的主從複製用 statement-based binlog（把 SQL 語句複製過去執行）。在 RC 下，主從兩邊執行同一批語句可能得到不同結果，會導致資料不一致。RR 加上 Gap Lock 才能保證順序一致。換句話說，這個預設值是為了複製的正確性，不是為了應用程式好用。

RR 的代價

• Gap Lock 多得多 → 鎖的範圍更大 → 並行度更低、死鎖機率更高
• 快照凍結整個交易 → 長事務造成的版本鏈問題更嚴重

什麼時候該考慮降到 RC

• 高並發寫入、而且已經被 Gap Lock 死鎖困擾
• 業務上能接受「同一個交易裡兩次讀到不同值」——大多數 Web 應用其實可以，因為一個請求通常只讀一次
• 已經改用 row-based binlog（現代 MySQL 的預設），沒有複製一致性的疑慮

什麼時候需要 SERIALIZABLE

幾乎不需要。它會把所有普通 SELECT 變成加鎖讀，並行度崩潰。真的需要嚴格一致性時，比較好的做法是：

• 樂觀鎖：加一個 version 欄位，更新時 WHERE version = ?，失敗就重試（JPA 的 @Version）
• 悲觀鎖但範圍極小：只在那一行關鍵操作用 SELECT ... FOR UPDATE
• 把衝突移出資料庫：用分散式鎖或佇列讓衝突根本不會同時發生