您好,登錄后才能下訂單哦!
本篇內容介紹了“SQL中的ACID指的是什么”的有關知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠學有所成!
WAL的中心思想是對數據文件的修改(它們是表和索引的載體)必須是只能發生在這些修改已經記錄了日志之后,也就是說,在日志記錄沖刷到永久存儲器之后。
如果我們遵循這個過程,那么我們就不需要在每次事務提交的時候都把數據頁沖刷到磁盤,因為我們知道在出現崩潰的情況下,
我們可以用日志來恢復數據庫:任何尚未附加到數據頁的記錄都將先從日志記錄中重做(這叫向前滾動恢復,也叫做REDO)然后那些未提交的事務做的修改將被從數據頁中刪除(這叫向后滾動恢復-UNDO)。
一個事務可以封裝狀態改變(除非它是一個只讀的)。
事務必須始終保持系統處于一致的狀態,不管在任何給定的時間并發事務有多少。
也就是說:如果事務是并發多個,系統也必須如同串行事務一樣操作。
其主要特征是保護性和不變性(PreservinganInvariant),以轉賬案例為例,假設有五個賬戶,每個賬戶余額是100元,那么五個賬戶總額是500元
如果在這個5個賬戶之間同時發生多個轉賬,無論并發多少個,比如在A與B賬戶之間轉賬5元,在C與D賬戶之間轉賬10元,在B與E之間轉賬15元,五個賬戶總額也應該還是500元,這就是保護性和不變性。
整個事務中的所有操作,要么全部完成,要么全部不完成,不可能停滯在中間某個環節。
事務在執行過程中發生錯誤,會被回滾(Rollback)到事務開始前的狀態,就像這個事務從來沒有執行過一樣。
在事務提交完成以后,該事務對數據庫所做的更改便持久的保存在數據庫之中,永久保存下來,并不會被回滾。
隔離狀態執行事務,使它們好像是系統在給定時間內執行的唯一操作。
如果有兩個事務,運行在相同的時間內,執行相同的功能,事務的隔離性將確保每一事務在系統中認為只有該事務在使用系統。
這種屬性有時稱為串行化,為了防止事務操作間的混淆,必須串行化或序列化請求,使得在同一時間僅有一個請求用于同一數據。
由于一項操作通常會包含許多子操作,而這些子操作可能會因為硬件的損壞或其他因素產生問題,要正確實現ACID并不容易。
ACID建議數據庫將所有需要更新以及修改的資料一次操作完畢,但實際上并不可行。
目前主要有兩種方式實現ACID:第一種是Writeaheadlogging,也就是日志式的方式(現代數據庫均基于這種方式)。第二種是Shadowpaging。
相對于WAL(writeaheadlogging)技術,shadowpaging技術實現起來比較簡單,消除了寫日志記錄的開銷恢復的速度也快(不需要redo和undo)。
“SQL中的ACID指的是什么”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站,小編將為大家輸出更多高質量的實用文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。