資料庫的基石：一次搞懂交易的四大守護神 ACID

發表於 2025-08-19 分類於技術筆記

當開發應用程式時，無論是電商網站的訂單系統、銀行的轉帳功能，還是社群平台的發文留言，背後都離不開與資料庫的互動。我們都希望資料是正確、可靠且一致的。但要如何確保在高併發、網路不穩定甚至系統當機的複雜環境下，資料依然能保持「高枕無憂」的狀態呢？

答案，就藏在資料庫系統的核心設計哲學中——ACID 原則。

什麼是「交易」(Transaction)？

在深入 ACID 之前，必須先理解什麼是「交易」。

在資料庫中，交易是一連串操作的集合，這些操作被視為一個不可分割的最小工作單元。這個單元裡的所有操作，要麼全部成功，要麼全部失敗。

最經典的例子就是銀行轉帳：

從 A 帳戶扣除 1000 元。
在 B 帳戶增加 1000 元。

這兩個動作必須被綁定在一個「交易」中。絕對不希望只完成了第一步，系統就當機了，那 A 的錢就憑空消失了！而 ACID 原則，正是為了確保這種交易能夠安全可靠地完成。

ACID 的四大核心成員

ACID 是四個單字的首字母縮寫，分別代表著：

Atomicity (原子性)
Consistency (一致性)
Isolation (隔離性)
Durability (持久性)

A - Atomicity (原子性)：成敗與共，絕不單飛

原子性確保一個交易中的所有操作是「一個完整的整體」，就像化學中的原子一樣，不可再分割。這意味著：所有操作要麼全部完成，要麼全部都不做。如果交易中的任何一個環節失敗，整個交易就會被回滾 (Rollback) 到最初的狀態，彷彿什麼事都沒發生過。

生活化比喻：
這就像去 ATM 提款。整個「交易」包含：插卡 -> 輸入密碼 -> 輸入金額 -> 吐鈔 -> 帳戶扣款 -> 退卡。
如果在「吐鈔」環節機器卡住了，絕對不希望「帳戶扣款」這個動作還被執行。原子性能保證，一旦吐鈔失敗，整個交易就會被取消，帳戶餘額會恢復原狀。

在 SQL 中，通常使用 BEGIN TRANSACTION, COMMIT (提交) 和 ROLLBACK (回滾) 來控制交易的原子性。

BEGIN TRANSACTION;

-- 步驟 1: 從 A 帳戶扣款
UPDATE Accounts SET balance = balance - 1000 WHERE user_id = 'A';

-- 假設此處發生了某個錯誤！
-- 例如：B 帳戶不存在或系統崩潰

-- 步驟 2: 為 B 帳戶存款
UPDATE Accounts SET balance = balance + 1000 WHERE user_id = 'B';

-- 如果中間出錯，整個交易會被 ROLLBACK
-- 如果一切順利，執行 COMMIT
COMMIT;

C - Consistency (一致性)：規則至上，絕不妥協

一致性確保資料庫的狀態在交易開始前和結束後，都必須滿足所有的預設規則和約束 (例如：欄位類型、不得為空、主鍵唯一性、外鍵關聯等)。換句話說，一個交易不能破壞資料庫的「完整性」。

資料庫本身並不創造一致性，而是提供機制來維持開發者定義的一致性。

生活化比喻：
想像一個圖書館的借書系統，規則是「每個用戶最多只能借 5 本書」。
當一個已經借了 5 本書的用戶再來借書時，一個符合一致性的交易會拒絕這次操作，因為執行後會破壞「最多 5 本」這個規則。交易結束後，資料庫的狀態依然是合法的。它確保了資料庫永遠不會進入一個「矛盾」或「非法」的狀態。

I - Isolation (隔離性)：你的世界，與我無關

在多使用者環境下，多個交易可能會同時發生 (併發)。隔離性確保一個交易的執行不會被其他正在同時執行的交易所干擾。從任何一個交易的角度來看，它都感覺好像是系統中唯一在運行的交易。

如果沒有隔離性，可能會發生以下問題：

髒讀 (Dirty Read): 一個交易讀取了另一個尚未提交的交易所修改的資料。
不可重複讀 (Non-repeatable Read): 一個交易內兩次讀取同一筆資料，結果卻不同，因為中間被其他交易修改並提交了。
幻讀 (Phantom Read): 一個交易內兩次執行相同的範圍查詢，但第二次查詢返回了第一次沒有的「幻影」行，因為其他交易在此期間插入了新資料。

生活化比喻：
你和另一個人同時在網上搶購最後一張演唱會門票。
隔離性確保系統會將你們倆的操作隔離開來。系統會先處理一個人的請求（比如你的），鎖定這張票，完成整個付款流程。在這期間，另一個人看到的狀態可能是「正在處理」或「已售罄」，而不會讓他也能進入付款頁面，導致一張票賣給兩個人。

資料庫通常提供不同的隔離級別 (如 Read Uncommitted, Read Committed, Repeatable Read, Serializable)，讓開發者在效能和資料一致性之間做取捨。

D - Durability (持久性)：一諾千金，永不遺失

持久性保證一旦交易被成功提交 (Commit)，它對資料庫所做的更改就是永久性的。即使之後系統發生崩潰、斷電或其他故障，這些已提交的修改也不會丟失。

資料庫通常透過預寫日誌 (Write-Ahead Logging, WAL) 等技術來實現持久性。在修改實際資料前，系統會先把操作記錄到一個穩定的日誌檔案中。這樣即使系統崩潰，重啟後也能透過日誌來恢復資料，確保已提交的交易不會遺失。

生活化比喻：
當在網路上完成付款，並收到「交易成功」的確認訊息時，這個結果就是持久的。不用擔心商家下一秒說因為他們伺服器斷電了，所以訂單不算數。這個「承諾」已經被永久地記錄下來了。

總結：為何 ACID 如此重要？

原則	核心概念	口語化解釋
Atomicity	不可分割	一家人要整整齊齊，要麼一起成功，要麼一起失敗。
Consistency	狀態合法	做人要有底線，做事要守規矩，不能讓資料庫陷入混亂。
Isolation	互不干擾	你走你的陽關道，我過我的獨木橋，我們互不影響。
Durability	永久保存	說出去的話，潑出去的水，一旦承諾，永久有效。

ACID 原則是關聯式資料庫管理系統 (RDBMS) 如 MySQL、PostgreSQL 等的基石。它為我們提供了一個強大的承諾：資料是可靠的。這使得開發者可以專注於業務邏輯，而不必過度擔心底層資料在各種極端情況下的完整性問題。

當然，在某些場景下（特別是需要極高吞吐量的 NoSQL 資料庫），人們會選擇犧牲部分 ACID 特性（尤其是 C 和 I），來換取更高的效能和可用性，這就是所謂的 BASE 理論 (Basically Available, Soft state, Eventually consistent)，但這就是另一個有趣的話題了。