資料世界的「嚴酷現實」：很多事都會出錯

第 7 章一開場，作者沒有先講漂亮的理論，而是先把「真實世界會出事的清單」整份攤開給你看。為什麼要先講壞消息？因為只有先體會過混亂，你才會明白後面要學的 交易（Transaction） 為什麼是個救星。

書中列出六種典型的 部分失敗 情境，我們把它拆開看：

直接讀原文：交易到底承諾了什麼

這一段是全章的地基句——先讀原文，感受作者怎麼用最精簡的英文，把「交易」這個概念一句話講清楚。

先幫你分類：資料世界的種種意外

把上一屏的六種意外，收斂成書中真正討論的重點類別——這幾張卡片，之後每次遇到「系統又出怪事了」，都可以拿出來對照。

跑一遍看看：同一次轉帳，有沒有交易差在哪

應用程式要做一連串寫入（例如轉帳：A 扣款、B 加款）。按「下一步」，先看「沒有交易保護」中途當機會多慘，接著看「有交易保護」時資料庫怎麼幫你善後。

兩個極端迷思，作者都不買單

2000 年代末 NoSQL 資料庫爆紅，很多新世代資料庫乾脆拋棄交易，或把「交易」重新定義成弱很多的保證。江湖上於是出現兩派極端說法：

小試身手

資料世界的意外清單、還有交易的「全有或全無」承諾，來檢查一下有沒有抓到重點。

「ACID compliant」聽起來很安心，但它其實沒告訴你什麼

資料庫要展示自己「靠得住」，最常搬出來的招牌就是 ACID。 這四個字母是 1983 年 Theo Härder 與 Andreas Reuter 提出的，目的是替「資料庫的容錯機制」建立一套精確術語。聽起來很嚴謹，對吧？

但書裡直接潑了一盆冷水：一家資料庫的 ACID 實作，不等於另一家的實作。「高層次的概念」本身是健全的，問題出在細節——尤其是 隔離性（Isolation） 的含義，各家解讀天差地別。結果就是，當一個系統說自己「ACID compliant」時，你其實搞不清楚它到底保證了什麼——ACID 很遺憾地大多變成了一個行銷詞彙。

那不符合 ACID 標準的系統呢？它們有時被叫做 BASE ——聽起來更玄，但書中直言，BASE 唯一說得通的定義，幾乎就是「反正不是 ACID」，幾乎可以指任何你想要的東西。

直接讀原文：A、I、D 才是資料庫的，C 呢？

這一段是整章最關鍵的反轉。書裡把四個字母拆開，你會發現三個是資料庫的責任，剩下那個字母，其實另有主人。

點點看：拆開四個字母，各自的真面目

別再把 ACID 當成一整塊招牌背下來。點下面四張卡片，看每個字母在「實務上」真正代表什麼——跟你直覺想的可能不太一樣。

值得注意的是， 可中止性（abortability） 這個詞，其實比原子性更能點出這個保證的本質——因為多執行緒程式裡的「atomic」講的是別人看不到中間狀態，那其實對應到 ACID 的 隔離性， 跟原子性是兩件不同的事。

A 和 I 真正的舞台：一個物件，還是好幾個？

原子性和隔離性的定義，其實都預設了一件事：你想同時修改「好幾個」物件（rows、documents、records）。這種交易就叫 多物件交易。

動手配配看：這是「單一物件」還是「多物件」操作？

把下面幾個操作，拖到它該歸類的分類。配完按「對答案」。

小試身手

ACID 四個字母的真面目、還有多物件交易的道理，來檢查一下有沒有記牢。

並行 bug：只在「時機不巧」才現身的幽靈

先講一個原則：如果兩個交易碰的不是同一筆資料，它們可以放心平行跑，彼此互不相干。 並行（concurrency） 真正會出事，只有兩種情況：一個交易在讀某筆資料，卻被另一個交易同時改掉；或是兩個交易同時想改同一筆資料。這時就出現了 競態條件（race condition）。

最經典的例子：兩個 client 同時對一個值是 42 的計數器做「讀取 → 加 1 → 寫回」。理應變成 44，但如果時機不巧——A 讀到 42、B 也讀到 42（A 還沒寫回）、A 寫回 43、B 也用過時的 42+1 寫回 43，蓋掉了 A——結果只有 43，一次遞增憑空消失。這叫 更新遺失（lost update）。

直接讀原文：弱隔離等級的登場理由

書上先把「隔離」的理想講清楚，再老實承認：現實中很少人真的付得起最強隔離的代價。

跑一遍時間軸：T1 還沒提交，T2 想讀、想寫，會怎樣？

兩筆交易 T1、T2 交錯動同一筆資料。按「下一步」，先看沒有防護時會出什麼問題，再看 Read Committed（讀已提交） 怎麼把這兩種問題擋下來。

Read Committed 擋得住什麼，擋不住什麼？

Read Committed 只給你兩個保證：讀的時候只看得到已提交的資料（防 髒讀 dirty read）， 寫的時候只覆寫已提交的資料（防 髒寫 dirty write）。 就這兩條。它不是萬靈丹——回到本節開頭那個計數器 42 的例子：兩個交易各自把計數器讀出、加 1、寫回，第二次寫回時第一筆交易早已 commit，所以覆寫的是「已提交值」——不是髒寫，Read Committed 樂意放行。結果兩次 +1 卻只加到 43，這就是更新遺失（lost update），要靠後面小節的原子操作或鎖來解。

100 元怎麼憑空消失的？認識讀偏斜與快照隔離

Alice 在銀行有 1,000 元存款，分散在兩個帳戶，各 500 元。系統正在把 100 元從帳戶 1 轉到帳戶 2——這其實是兩筆寫入：先扣帳戶 1（變成 400），再加帳戶 2（變成 600）。如果 Alice 運氣不好，剛好在這兩步「中間」查餘額，她可能讀到帳戶 1 已經扣完（400）、帳戶 2 還沒加上（500），加起來只有 900 元，100 元像是憑空蒸發了。

錢其實一塊都沒少，Alice 只是在錯誤的瞬間看到了不一致的中間狀態。這種現象叫 讀偏斜（read skew）， 又叫不可重複讀（nonrepeatable read）。在 Read Committed 等級下，這完全合法——因為 Alice 讀到的每個數字，在她讀的那一刻確實都是已提交的真實資料。

解方是 快照隔離（snapshot isolation）—— 核心思想一句話：每一筆交易都從資料庫的一致快照讀取，看到的是「交易開始那一刻」所有已提交的資料。之後即使別人改了資料，這筆交易仍只看到那個時間點凍結的舊資料。Alice 的查詢交易只會看到「轉帳前」或「轉帳後」的完整狀態，永遠不會撞見那個尷尬的 900 元中間態。

MVCC：博物館怎麼做到「從不丟掉舊展品」

快照隔離的實作關鍵祕密：資料庫從不真的覆蓋舊資料。這套機制叫 MVCC（多版本並行控制）。

小試身手

Read Committed 和快照隔離各自的邊界在哪裡？來兩題檢查一下。

先從最直覺的案例開始：計數器怎麼「加了兩次卻只加了一次」

資料庫裡有個計數器 value = 42，兩個交易都想幫它加 1。資料庫沒有內建的加法指令，程式只能自己做三步：讀出目前值、在記憶體裡改成新值、再寫回去——這叫 讀-改-寫循環。 一個人做沒事，兩個交易「同時」做，就會出事。

這就是 丟失更新（lost update）。 它常出現在遞增計數器／帳戶餘額、修改 JSON 文件裡的一個欄位、或兩人同時編輯同一個 wiki 頁面全文送回——本質都是讀-改-寫。

直接讀原文：書怎麼定義丟失更新

這一段是丟失更新問題最原汁原味的定義，順便列出它常出現的三種情境。

招牌案例：兩位值班醫生，各自的決定都合法，合起來卻違規

丟失更新至少還「蓋到了同一格資料」，看得出問題在哪。書中接下來這個案例更陰險——兩個交易改的是不同的物件，資料庫完全不覺得它們互相衝突。按「下一步」，看 Alice 和 Bob 怎麼一起搞砸值班表。

這個現象叫 寫入偏斜（write skew）。 它既不是髒寫、也不是丟失更新——因為 Alice 和 Bob 更新的是兩個不同的物件（各自的值班紀錄）。問題不在任何一步「寫錯」，而是「檢查條件」與「根據條件寫入」之間出現了空隙：兩人都基於同一份即將過期的 前提（premise）做判斷，而那個前提在他們做決定的同時，已經被對方的動作悄悄推翻了。

寫入偏斜的固定劇本，還有能防的招式

醫生值班、會議室預訂、多人遊戲棋子、帳號註冊、帳戶提款——書中列的例子表面不同，骨子裡都是同一套三步驟劇本：

醫生值班這個例子還算好處理：第 3 步要改的列，正好就是第 1 步查出來的列，所以能在第 1 步就用 SELECT ... FOR UPDATE 把那幾列鎖住，逼另一個交易排隊等待。書中在無法切到可序列化隔離時，就是建議用這招當第二選擇：

BEGIN TRANSACTION;
SELECT * FROM doctors
WHERE on_call = true AND shift_id = 1234 FOR UPDATE;
UPDATE doctors SET on_call = false
WHERE name = 'Alice' AND shift_id = 1234;
COMMIT;

幻讀：連鎖都掛不上去的敵人

幻讀的定義，就是：一個交易裡的寫入，改變了另一個交易某個搜尋查詢會匹配到的那組列。

會議室預訂就是幻讀的經典場景：兩個交易各自查「這個時段有沒有人訂」，都看到「沒有」，於是都插入了一筆新預訂——衝突來自一列當時根本還不存在、隨後才被插入的 列（phantom）。 解法叫 物化衝突（materializing conflicts）—— 先把「房間 × 時段」所有組合都預先建成一張表（純粹當鎖用，不存預訂內容），要訂房前先把對應的列鎖起來，幻讀就變成了實體列上的鎖衝突。

動手配配看：三種異常，該用哪招防？

把下面三種並行異常，拖到它最對症的防範招式。配完按「對答案」。

小試身手

丟失更新、寫入偏斜、幻讀，這三個名詞背後的判斷力，來檢查一下有沒有抓對。

前面擋了一半，這次要把話說死

一路看下來，我們已經見過 dirty read、 lost update、 write skew、 phantom——一堆會讓人半夜爬起來查 log 的並行災難。較弱的隔離等級，像 read committed、snapshot isolation，都只擋掉其中一部分，剩下的還是會漏。

更麻煩的是：隔離等級的名稱本身就很混亂（不同資料庫的「repeatable read」意義完全不同），你也很難判斷自己的程式在某個隔離等級下到底安不安全——尤其並行問題是 不確定性（nondeterministic） 的，運氣不好、時序剛好對上才會爆，幾乎無法穩定測試出來。

從 1970 年代開始，研究者給的答案一直很直接：用 serializability（可序列化） 就好。

那為什麼不是大家都在用？因為它有代價——最強的保證通常最貴。所以重點從來不是「該不該用」，而是「怎麼實作才不會太慢」。接下來我們會先快速認識三種主流做法，再把重點放在其中最常見的一種：兩階段鎖定。

直接讀原文：兩階段鎖定的核心規則

這一段是全書講兩階段鎖定最關鍵的定義句——鎖怎麼分兩種模式、怎麼互相卡住，一句一句對照著看。

動畫演給你看：一次鎖升級是怎麼被卡住的

交易 T1 想先讀一列資料、再改它；交易 T2 這時已經持有衝突的鎖。按「下一步」，看 T1 怎麼從「共享鎖」走到「被鎖管理器擋下來」，直到 T2 結束才被放行。

兩階段鎖定的三條運作規則

把上面的動畫拆成規則寫下來，就是這三條——資料庫靠它們讓「寫擋讀、讀擋寫」，反過來擋掉幾乎所有並行災難。

小試身手

可序列化的承諾、還有兩階段鎖定的運作方式，來檢查一下有沒有記牢。

兩種看待衝突的人生觀

資料庫要保證 可序列化， 但要怎麼達成？書裡把做法分成兩種根本不同的「個性」。

直接讀原文：悲觀 vs 樂觀並行控制

這一段是全書對兩種並行控制哲學最精準的定義，逐句對照白話。

跑一遍看看：SSI 的樂觀流程

下面把 SSI 處理一筆交易的過程拆成幾步。按「下一步」，看交易怎麼從「樂觀地跑」走到「提交時才驗收」。

要抓的兩種「過時」，方向剛好相反

資料庫要問的只有一句話：「查詢結果有沒有可能已經變了？」答案分成兩種情境，剛好對應「修改在我讀之前」跟「修改在我讀之後」。

SSI 快在哪、又該在什麼情境下選它

SSI 的效能表現，可以濃縮成三個特性：

那什麼時候該選 SSI？書中把關鍵濃縮成兩句：高競爭時表現差——很多交易搶同一批物件，大量中止重試，若系統已接近最大吞吐量，重試帶來的額外負載會讓效能雪上加霜；低競爭又有備援容量時表現更好——樂觀法往往勝過悲觀法。想降低競爭，還能改用可交換的原子操作，例如多個交易都要對同一計數器 +1，順序無所謂，這些並行遞增就能互不衝突地全部套用。

全章總結：隔離等級的光譜

整章走完一輪，我們把所有隔離等級擺回同一條光譜上——等級越強，擋下的並行災難越多：

來做最後兩題，檢查一下悲觀 vs 樂觀、以及 SSI 效能特性有沒有記牢。