ACID保護您的數據庫的數據
數據庫設計的ACID模型是數據庫理論中最古老也是最重要的概念之一。 它提出了每個數據庫管理系統必須努力實現的四個目標：原子性，一致性，隔離性和持久性。 不能滿足這四個目標中的任何一個的關係數據庫不能被認為是可靠的。 擁有這些特性的數據庫被認為符合ACID標準。
ACID定義
讓我們花點時間仔細檢查每個特徵：
- Atomicity聲明數據庫修改必須遵循“全部或全部”規則。 每筆交易都被稱為“原子”。如果交易的一部分失敗，整個交易將失敗。 數據庫管理系統儘管存在任何DBMS，操作系統或硬件故障，仍然保持事務的原子性質，這一點至關重要。
- 一致性規定只有有效的數據將寫入數據庫。 如果出於某種原因執行違反數據庫一致性規則的事務，則整個事務將被回滾，並且數據庫將被恢復到與這些規則一致的狀態。 另一方面，如果事務成功執行，它將使數據庫從一個與規則一致的狀態到另一個與規則一致的狀態。
- 隔離要求同時發生的多個事務不會影響彼此的執行。 例如，如果Joe在Mary發布不同事務的同時針對數據庫發出事務，則兩個事務都應以隔離的方式在數據庫上運行。 數據庫應該在執行Mary's之前執行Joe的整個事務，反之亦然。 這可以防止Joe的事務讀取作為Mary事務的一部分副作用而產生的中間數據，這些事務最終不會被提交給數據庫。 請注意，隔離屬性並不能確保首先執行哪個事務 - 只是這些事務不會相互干擾
- 持久性確保任何提交給數據庫的事務都不會丟失。 通過使用數據庫備份和事務日誌來確保持久性，這些備份和事務日誌有助於恢復承諾事務，儘管會出現任何後續軟件或硬件故障。
ACID在實踐中的工作原理
數據庫管理員使用多種策略來強制執行ACID。
一種用於強制原子性和持久性的方法是預寫式日誌記錄 （WAL），其中任何事務細節首先被寫入到包含重做和撤消信息的日誌中。這確保了在任何類型的數據庫故障的情況下，數據庫可以檢查日誌並將其內容與數據庫的狀態進行比較。
用於解決原子性和持久性的另一種方法是陰影分頁 ，其中在要修改數據時創建陰影頁面。 查詢的更新被寫入影子頁面而不是數據庫中的真實數據。 數據庫本身僅在編輯完成時才被修改。
另一種策略稱為兩階段提交協議，在分佈式數據庫系統中尤其有用。 該協議將修改數據的請求分為兩個階段：提交請求階段和提交階段。 在請求階段，網絡上受交易影響的所有DBMS必須確認他們已收到並有能力執行交易。 一旦從所有相關的DBMS接收到確認，提交階段就會完成，其中數據實際上被修改。