您好,登錄后才能下訂單哦!
下文主要給大家帶來MySQL數據庫事務知識,希望這些內容能夠帶給大家實際用處,這也是我編輯MySQL數據庫事務知識這篇文章的主要目的。好了,廢話不多說,大家直接看下文吧。
只有InnoDB引擎支持事務,下邊的內容均以InnoDB引擎為默認條件
一個事務讀取了另一個事務未提交的數據
一個事務對同一數據的讀取結果前后不一致。兩次讀取中間被其他事務修改了
幻讀是指事務讀取某個范圍的數據時,因為其他事務的操作導致前后兩次讀取的結果不一致。幻讀和不可重復讀的區別在于,不可重復讀是針對確定的某一行數據而言,而幻讀是針對不確定的多行數據。因而幻讀通常出現在帶有查詢條件的范圍查詢中
可能產生臟讀、不可重復讀、幻讀
避免了臟讀,可能產生不可重復讀、幻讀
避免了臟讀,不可重復讀。通過區間鎖技術避免了幻讀
串行化可以避免所有可能出現的并發異常,但是會極大的降低系統的并發處理能力
undo日志用于存放數據修改被修改前的值
UNDO LOG中分為兩種類型,一種是 INSERT_UNDO(INSERT操作),記錄插入的唯一鍵值;
一種是 UPDATE_UNDO(包含UPDATE及DELETE操作),記錄修改的唯一鍵值以及old column記錄。
mysql會將一個事務中的所有sq先l記錄到redo log中,然后再將記錄從redo log同步到數據文件中
它可以帶來這些好處:
當buffer pool中的dirty page 還沒有刷新到磁盤的時候,發生crash,啟動服務后,可通過redo log 找到需要重新刷新到磁盤文件的記錄;
buffer pool中的數據直接flush到disk file,是一個隨機IO,效率較差,而把buffer pool中的數據記錄到redo log,是一個順序IO,可以提高事務提交的速度;
用于數據庫主從復制的記錄,是二進制格式。在事務提交之后進行一個磁盤寫入。
這里注意下redo log 跟binary log 的區別,redo log 是存儲引擎層產生的,而binary log是數據庫層產生的。假設一個大事務,對tba做10萬行的記錄插入,在這個過程中,一直不斷的往redo log順序記錄,而binary log不會記錄,直到這個事務提交,才會一次寫入到binary log文件中
1、默認情況下,開啟事務自動提交功能。每執行一個sql,都會對應一個事務的提交
2、 spring會將底層連接的自動提交特性設置為false。使用手動提交
事務中的所有操作作為一個整體像原子一樣不可分割,要么全部成功,要么全部失敗。
事務的執行結果必須使數據庫從一個一致性狀態到另一個一致性狀態。一致性狀態是指:1.系統的狀態滿足數據的完整性約束(主碼,參照完整性,check約束等) 2.系統的狀態反應數據庫本應描述的現實世界的真實狀態,比如轉賬前后兩個賬戶的金額總和應該保持不變。https://wenku.baidu.com/view/6bb581fdae45b307e87101f69e3143323868f5eb
并發執行的事務不會相互影響,其對數據庫的影響和它們串行執行時一樣。比如多個用戶同時往一個賬戶轉賬,最后賬戶的結果應該和他們按先后次序轉賬的結果一樣。
事務一旦提交,其對數據庫的更新就是持久的。任何事務或系統故障都不會導致數據丟失。
讀取的是快照版本,也就是歷史版本。普通的SELECT就是快照讀
讀取的是最新版本。UPDATE、DELETE、INSERT、SELECT … LOCK IN SHARE MODE、SELECT … FOR UPDATE是當前讀。
在一個事務中,標準的SELECT語句是不會加鎖,但是有兩種情況例外。SELECT … LOCK IN SHARE MODE 和 SELECT … FOR UPDATE。
SELECT ... LOCK IN SHARE MODE
給記錄假設共享鎖,這樣一來的話,其它事務只能讀不能修改,直到當前事務提交
SELECT ... FOR UPDATE
給索引記錄加鎖,這種情況下跟UPDATE的加鎖情況是一樣的
對于以上關于MySQL數據庫事務知識,大家是不是覺得非常有幫助。如果需要了解更多內容,請繼續關注我們的行業資訊,相信你會喜歡上這些內容的。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。