你有沒有轉帳時突然斷線，結果錢從你帳戶扣了但對方沒收到？
如果銀行系統設計得好，這件事不會發生。ACID 就是確保資料庫交易「全做或全不做」的四個原則：原子性（要嘛全部完成，要嘛全部取消）、一致性（交易前後資料規則不能被破壞）、隔離性（多人同時操作不會互相干擾）、持久性（交易完成後資料永久保存，斷電也不會消失）。
任何涉及金錢、庫存、訂單的系統，都需要 ACID 來保證資料的正確性。
就像先用生活中的例子抓住核心用途，再回頭看名詞和公式，理解會穩很多。
容易混淆
ACID vs BASE vs CAP
ACID：強調即時一致性和可靠性，每筆交易都完整無誤。
BASE（Basically Available, Soft state, Eventually consistent）：追求高可用性，允許短暫的資料不一致，最終會一致。
CAP 定理：分散式系統中，一致性、可用性、分區容錯性三者最多只能同時滿足兩個。
最關鍵的區別：ACID 是「寧可慢一點也要保證資料正確」，BASE 是「先讓系統能用，資料晚一點再同步也沒關係」。
記住這句就好
要嘛全做、要嘛全不做，資料不能只做一半。
實際案例
銀行轉帳
你從 A 帳戶轉 1000 元到 B 帳戶。原子性確保「A 扣款」和「B 入帳」要嘛同時成功、要嘛同時取消。如果中間系統當機，不會出現 A 扣了錢但 B 沒收到的情況。
電商庫存
兩個用戶同時搶最後一件商品。隔離性確保兩筆訂單不會同時成功，否則就會超賣。系統會讓兩筆交易排隊處理，第一筆成功後第二筆會看到庫存已經為零。
深入了解
ACID 四大特性詳解
特性 意思 實現方式 原子性（Atomicity） 交易中的所有操作要嘛全部完成，要嘛全部回滾 交易日誌（Transaction Log） 一致性（Consistency） 交易前後資料必須符合所有約束和規則 約束檢查、觸發器 隔離性（Isolation） 同時進行的交易互不干擾 鎖定機制、MVCC 持久性（Durability） 交易完成後資料永久保存，即使系統故障也不會遺失 WAL（Write-Ahead Logging）
情境判斷
Q1（直覺題）： 你在設計一個線上購票系統，同一個座位可能被多人同時選購。你最需要 ACID 的哪個特性？
→ 隔離性。多個用戶同時搶同一個座位，隔離性確保不會重複售出。
Q2（判斷題）： 你的社群媒體 App 需要顯示「按讚數」，偶爾顯示的數字比實際少 1-2 個。你需要嚴格遵守 ACID 嗎？
→ 不需要。按讚數的短暫不一致對用戶體驗影響很小，使用 BASE 模型（最終一致性）反而能獲得更好的效能和可用性。ACID 適合金融交易等對正確性要求極高的場景。
常見問題
NoSQL 資料庫支援 ACID 嗎？
部分支援。早期 NoSQL 為了效能犧牲了 ACID，但現代 NoSQL 如 MongoDB 4.0+ 已經支援多文檔交易的 ACID 特性。不過通常效能會比不使用 ACID 時差。
ACID 會影響效能嗎？
會。確保 ACID 需要額外的鎖定、日誌、同步等開銷，在高併發場景下可能成為效能瓶頸。所以不是所有系統都需要完整的 ACID，要根據業務需求選擇。
雲端資料庫如何處理 ACID？
雲端資料庫（如 AWS Aurora、Google Spanner）用分散式交易協議來實現跨節點的 ACID。Google Spanner 甚至用原子鐘來解決全球分散式環境下的一致性問題。