資料庫 ACID 的原子性是什麼？
在資料庫的 ACID 特性中，下列何者為「原子性（Atomicity）」的正確定義？
資料庫有一組保護資料正確性的特性，縮寫叫 ACID。其中一個叫「原子性（Atomicity）」。
問你：「原子性」的正確定義是什麼？
一句話總結
原子性（Atomicity）的定義：一筆交易裡的所有操作，要嘛全部成功，要嘛全部失敗，沒有「做一半」的中間狀態。
先感受問題：銀行轉帳的兩步驟
阿仁用嘉誠銀行 App 轉帳 1 萬元給朋友小薇：
步驟 2：小薇帳戶 +10,000 元
如果在步驟 1 完成、步驟 2 執行前，伺服器突然當機怎麼辦？
- 沒有原子性保護：阿仁少了 1 萬，小薇沒有收到，錢憑空消失。
- 有原子性保護：步驟 2 失敗 → 整筆交易自動回滾（Rollback）→ 步驟 1 也取消 → 阿仁帳戶回到原狀，就像什麼都沒發生。
原子性保證：轉帳這個「交易」是一個不可分割的整體，中途失敗就全部取消。
沒有原子性保護時，資料庫會有什麼問題
- 資料不一致：轉帳做一半失敗，帳本裡一邊少錢一邊沒加錢，總金額對不上。
- 難以回復到正常狀態：不知道哪些步驟成功、哪些失敗，手動修復非常困難。
- 複雜業務邏輯的崩潰點更多：一個電商訂單可能包含「扣庫存 + 扣款 + 建訂單記錄」三個步驟，任一步驟失敗都可能造成髒資料。
- 難以保證審計正確性：財務報告、交易紀錄必須每一筆都完整，部分失敗的交易會讓帳目難以核對。
- 系統重啟後狀態不明：不確定上次執行到哪一步，系統重啟後不知道要從哪裡恢復。
原子性：全部做完，或全部不算
原子性的設計靈感來自「原子」（Atom）這個概念：最小的不可分割單位。一筆資料庫交易就是一個「原子」，裡面有幾個操作，要嘛全部執行成功，要嘛就像從來沒執行過。
技術實作：資料庫透過「交易日誌（Transaction Log）」記錄每個步驟，一旦有步驟失敗，就把已完成的步驟全部回滾（Rollback），回到交易開始前的狀態。
口訣：All or Nothing——全部成功，或全部取消。
這就是選項 C 講的：交易不可分割，需完全成功或完全失敗。
技術版：ACID 四個特性的完整說明
ACID 是關聯式資料庫保證交易正確性的四個特性：
- A - Atomicity（原子性）：交易不可分割，All or Nothing。
- C - Consistency（一致性）：交易執行前後，資料庫必須符合所有約束條件（例如帳戶餘額不能為負數）。
- I - Isolation（隔離性）：多個並行交易互不干擾，每個交易看到的資料就好像只有自己在執行一樣。
- D - Durability（持久性）：交易一旦成功（Commit），即使系統崩潰，資料也不會丟失（已寫入磁碟）。
記憶口訣（對應選項的干擾）：
- 「所有欄位相同型別」→ 這是資料型態約束，不是 ACID 的任何一條
- 「批次執行」→ 跟原子性無關，是效能優化的概念
- 「自動同步至所有節點」→ 這是分散式系統的一致性（CAP 定理的 C），不是 ACID 的原子性
NoSQL 資料庫通常不完整支援 ACID（尤其是隔離性），換取更高的可擴展性（Scalability）。這是 CAP 定理的取捨。
為什麼其他選項是錯的
A所有資料欄位必須為相同型別
同一張表的所有欄位，資料型別必須一樣（都是整數，或都是字串）。
這不是 ACID 的任何一條。一張表的欄位可以有不同型別（ID 是整數、姓名是字串、金額是浮點數）。這個說法完全跟資料庫交易的概念無關，更不是原子性的定義。
對資料庫概念不熟，以為原子性在講「資料的最小單位是型別一致」的人。原子性是關於交易操作的完整性，不是資料型態的規範。
B每次交易需以批次方式執行
交易要批次（Batch）執行，不能一個一個做。
「批次執行」是效能優化的做法（一次提交多個操作減少 I/O），跟原子性完全無關。原子性說的是「一筆交易內的多個操作要嘛全做要嘛全不做」，不是說要批次執行。
把「批次」和「原子」混為一談的人。記住：「批次」是效能概念，「原子性」是正確性概念，兩個是不同維度的東西。
D系統會自動同步交易資料至所有節點
一筆交易成功後，資料會自動同步到分散式系統的所有伺服器節點。
這描述的是分散式系統的「一致性（Consistency）」或「複製（Replication）」，不是 ACID 的原子性。ACID 的原子性說的是單一交易的 All or Nothing，跟多節點同步無關。
把「分散式一致性」跟「ACID 原子性」搞混的人。CAP 定理裡的一致性（Consistency）跟 ACID 的一致性是不同的概念，更不是原子性。
同個考點下次怎麼變形
ACID 的「持久性（Durability）」是什麼？
既然有原子性，交易成功後資料一定存起來了吧？持久性在說什麼？
持久性保證：一旦交易 Commit（確認成功），資料就算系統馬上當機也不會丟失。資料庫透過寫入磁碟（Write-Ahead Log）確保持久性，重啟後能從日誌恢復。
ACID 的「隔離性（Isolation）」如果不存在，會發生什麼？
同時有兩個交易在讀寫同一筆資料，沒有隔離性的話？
可能發生「髒讀（Dirty Read）」：交易 A 讀到了交易 B 還沒完成（尚未 Commit）的中間值，但 B 後來 Rollback 了。A 拿到的資料就是無效的。隔離性透過鎖定機制或 MVCC（多版本並行控制）解決這個問題。
NoSQL 資料庫通常為什麼不完全支援 ACID？
NoSQL 為什麼要放棄 ACID 的保護？
ACID 的嚴格保證會降低效能和可擴展性。NoSQL 為了支援大規模水平擴展（分散在很多台機器）、高寫入速度，通常放寬隔離性或一致性要求（使用「最終一致性」Eventual Consistency），換取更高的吞吐量。這是 CAP 定理中 Consistency vs Availability 的取捨。
「Rollback（回滾）」在原子性中扮演什麼角色？
交易失敗了，資料庫怎麼讓「已完成的步驟取消」？
Rollback 是實現原子性的機制：資料庫在開始交易時記錄一個「起點」，執行過程中把每個操作寫入交易日誌（Transaction Log）。若某個步驟失敗，就從日誌把之前的操作「反向執行」，讓資料庫回到交易開始前的狀態。這就是 All or Nothing 的技術實作。
在大數據處理管線中，原子性的精神如何體現？
Spark、Flink 這些大數據工具有類似原子性的概念嗎？
有，在批次處理中通常用「先寫暫存（Staging），驗證成功再移到正式區」的模式，確保資料要嘛完整落地要嘛不動正式資料。Spark Streaming 和 Kafka 也有「恰好一次（Exactly-once）」語意，保證每筆資料被處理且只被處理一次，這是原子性精神在流處理中的體現。
想再往下看，這 5 個
- ACID（ACID）核心考點，關聯式資料庫保證交易正確性的四個特性，原子性是其中第一個。
- 資料倉儲（Data Warehouse）企業級資料儲存系統，ACID 特性保護其中大量批次交易的資料完整性。
- 資料管線（Data Pipeline）在 ETL 流程中，原子性確保資料批次載入要嘛全部成功，要嘛全部回滾，避免髒資料進入倉儲。
- 資料品質監控（Data Quality Monitoring）ACID 的保護是資料品質的基礎，確保每一筆交易不會留下不完整的資料。
- 資料版本控制（Data Versioning）類似原子性，資料版本控制也確保版本的完整性，讓每次資料更新要嘛全部提交要嘛退回前一版本。