ACID中的'D'表示維基百科定義的「耐久性」：「每一筆交易都受到保護，以防止電力損失/死機/錯誤，並且系統不會丟失，因此可以保證完成」。典型的ACID RDBMS是否每次提交都同步到磁盤？
但是，這意味着每個事務都必須在被報告爲成功之前同步到磁盤，而不僅僅是刷新。 （'flush'=發送到操作系統級別，'sync'=發送到物理磁盤盤片）。這將使得實現高事務率RDBMS成爲不可能。
做流行的RDBMS是否真的同步每一筆交易？
使用磁盤進行持久化的數據庫確實必須寫入磁盤以使事務持久。而且，它們還必須同步到磁盤以避免寫回緩存造成任何損失。
爲了實現高性能，數據庫將使用組提交，因此提交循環中的多個事務將使用相同的寫入/同步操作來使所有事務都持久。這是可能的，他們都附加到相同的事務日誌。
這可能意味着單個提交的響應可能會延遲（等待其他人加入提交週期），但整個數據庫的整體吞吐量要高得多，因爲寫入/同步的成本會在整個期間攤銷多筆交易。例如，每個單獨的事務可能需要10mS，但成千上萬的事務都能夠在同一個週期內提交。
數據庫測量有多少事務處於活動狀態以判斷是否值得讓任何單個事務等待其他人加入提交週期，這樣在一個負載很輕的系統上，事務不需要等待其他。
並非所有的數據庫都使用磁盤來保證耐久性。例如，VoltDB依靠跨多個服務器存儲在內存中的事務副本。如果其中一臺服務器死亡，該交易仍可在其他地方使用。因此，交易只需要確保交易已傳輸到足夠多的服務器以確保持久性。
這也提出了什麼是耐用的問題？單個磁盤是否持久？不是如果磁盤失敗。 RAID陣列是否持久？如果存在災難性的RAID損壞，則不行。持久性的唯一保證是在多個遠程數據庫實例中複製事務的地方 - 但並非每個人都需要這種保證。耐用性不應被視爲二元期權，而應視爲耐久性水平的選擇。
'磁盤'不僅僅是一個文件。提交會寫入transaction log，然後用於更新數據庫。如果系統在更新之前崩潰，則可以從日誌中重建事務。
是 - 它被稱爲回退日誌。
爲什麼你認爲這是不可能的？
而且，如果您說每個事務都沒有同步，那麼您提出什麼解決方案？
我認爲這是不可能的，因爲在大多數同步操作中很難避免磁盤移動或其他與磁盤相關的開銷，並且這會將每秒的事務數減少到100或1000，而不是10,000。我沒有解決方案。 –
提交需要同步事務日誌，而不是刷新它。即使您設法避免磁盤磁頭移動，操作系統也需要對磁盤控制器進行大量對話，以獲取通常爲非常少量數據的信息。 –
你的問題是「是否流行的RDBMS真的同步每一筆交易？」答案是「是的，如果數據庫管理系統說它已經提交，它已經提交。「 – Dave