數據庫事務 ACID 四大特性深度解析：從銀行轉賬看原子性、一致性、隔離性、持久性

什麼是數據庫事務？

事務是一組操作序列，作為不可分割的工作單元執行：要麼全做，要麼全不做。它是數據庫從一個一致性狀態轉換到另一個一致性狀態的載體。

ACID 四大特性詳細解讀

1. 原子性 —— 全有或全無

事務包含的所有操作，要麼全部成功提交，要麼全部失敗回滾。不存在「部分成功」的中間狀態。

銀行轉賬例子： 從賬戶 A 扣款 100 元、向賬戶 B 增加 100 元，這兩步必須同時成功或同時失敗。若扣款成功但增加失敗，系統自動回滾扣款，避免資金憑空消失。

2. 一致性 —— 狀態正確轉換

事務執行前後，數據庫必須滿足所有完整性約束（主鍵、外鍵、CHECK、觸發器等業務規則）。

銀行轉賬例子： 轉賬前後，A+B 總金額不變。若事務中間暫時違背約束（如 A 扣款後 B 未增款），對外不可見；只有事務提交後，新狀態才對外可見，且必須滿足總額不變的約束。

3. 隔離性 —— 併發事務互不干擾

多個事務併發執行時，每個事務看到的數據狀態，要麼是另一事務開始前的狀態，要麼是另一事務提交後的狀態，絕不看到「進行中」的中間狀態。

隔離級別（由低到高）：

• READ UNCOMMITTED：可讀未提交數據（髒讀）。
• READ COMMITTED：默認級別，防髒讀，但不可重複讀、幻讀可能發生。
• REPEATABLE READ：防髒讀、不可重複讀，但幻讀可能發生。
• SERIALIZABLE：最高級別，完全串行化，防幻讀，性能最低。

實際系統常用 READ COMMITTED + 行版本控制（如 SQL Server 的 READ_COMMITTED_SNAPSHOT）平衡性能與一致性。

4. 持久性 —— 提交即永久

事務一旦 COMMIT，其修改永久保存，即使系統崩潰、斷電、重啟也不丟失。依賴 WAL（Write-Ahead Logging）機制：日志先於數據頁落盤，崩潰恢復時通過日志重做/回滾。

事務實戰最佳實踐

1. 事務要短小：長事務持有鎖時間長，易導致阻塞、死鎖、日志暴漲。
2. 避免事務中調用外部服務：網絡延遲、超時會拉長事務，若外部服務失敗難以補償。
3. 合理設置隔離級別：高併發讀多寫少場景開啟 READ_COMMITTED_SNAPSHOT。
4. 異常處理必須 ROLLBACK：TRY...CATCH 中捕獲異常時顯式回滾，防止事務懸掛。