事務特點 ACID

ATOMICITY:原子性

一個事務必須被視為一個不可分割的最小工作單元，整個事務中的所有操作要么全部提交成功，要么全部失敗回滾，對于一個事務來說，不可能只執行其中的一部分操作，這就是事務的原子性

CONSISTENCY:一致性

數據庫總是從一個一致性的狀態轉換到另一個一致性的狀態。

ISOLATION:隔離性

通常來說，一個事務所做的修改在最終提交以前，對其他事務是不可見的。

DURABILITY:持久性

一旦事務提交，則其所做的修改不會永久保存到數據庫。

隔離級別：

READ UNCOMMITTED(未提交讀)

在READ UNCOMMITTED級別，事務中的修改，即使沒有提交，對其他事務也都是可見的。事務可以讀取未提交的數據，這也被稱為臟讀(Dirty Read)。這個級別會導致很多問題，從性能上來說，READ UNCOMMITTED不會比其他的級別好太多，但卻缺乏其他級別的很多好處，除非真的有非常必要的理由，在實際應用中一般很少使用。

READ COMMITTED(提交讀)

大多數數據庫系統的默認隔離級別都是READ COMMTTED(但MySQL不是)。READ COMMITTED滿足前面提到的隔離性的簡單定義：一個事務開始時，只能"看見"已經提交的事務所做的修改。換句話說，一個事務從開始直到提交之前，所做的任何修改對其他事務都是不可見的。這個級別有時候叫做不可重復讀(nonrepeatble read)，因為兩次執行同樣的查詢，可能會得到不一樣的結果

REPEATABLE READ(可重復讀)

REPEATABLE READ解決了臟讀的問題。該隔離級別保證了在同一個事務中多次讀取同樣記錄結果是一致的。但是理論上，可重復讀隔離級別還是無法解決另外一個幻讀(Phantom Read)的問題。所謂幻讀，指的是當某個事務在讀取某個范圍內的記錄時，另一個事務又在該范圍內插入了新的記錄，當之前的事務再次讀取該范圍的記錄時，會產生幻行(Phantom Row)。InnoDB和XtraDB存儲引擎通過多版本并發控制(MVCC，Multiversion Concurrency Control)解決了幻讀的問題。

SERIALIZABLE(可串行化)

SERIALIZABLE是最高的隔離級別。它通過強制事務串行執行，避免了前面說的幻讀的問題。簡單來說，SERIALIZABLE會在讀取每一行數據都加鎖，所以可能導致大量的超時和鎖爭用問題。實際應用中也很少用到這個隔離級別，只有在非常需要確保數據的一致性而且可以接受沒有并發的情況下，才考慮采用該級別。

MVCC背景：

MySQL事務默認使用REPEATABLE READ(可重復讀)隔離級別。該隔離級別還是會產生幻讀問題。即當某個事務讀取某個范圍的記錄時，另外一個事物在該范圍插入了新的記錄，那么之前的事務再次讀取該范圍的記錄時，會產生幻行。MySQL InnoDB就是通過多版本并發控制(MVCC)解決幻讀問題。

MVCC簡介：

MVCC將數據庫的行鎖與行的多個版本結合起來,只需要很小的開銷,就可以實現非鎖定讀,從而大大提高數據庫系統的并發性能.

MVCC實現原理：

MVCC保存某個時間點上的數據快照。一個事務內，看到的是同一個版本的快照，數據一致。不同事務在同一時間點看到的數據會不一致，因為他們得到的數據版本不一樣。InnoDB在每行記錄存在額外的隱藏字段，其中一列存儲行被更新的版本號,另外一列存儲行被刪除的版本號。每當一個事務開始的時候,innodb都會給這個事務分配一個遞增的版本號,所以版本號也可以被認為是事務號.對于每一個”查詢”語句,innodb都會把這個查詢語句的版本號同這個查詢語句遇到的行的版本號進行對比,然后結合不同的事務隔離等級,來決定是否返回該行。當隔離級別是REPEATABLE READ時，這種策略下，select、delete、 insert、 update語句如何操作：

1) SELECT 對于select語句，只有同時滿足了下面兩個條件的行，才能被返回:

?行的被修改版本號小于或者等于該事務號

?行的被刪除版本號要么沒有被定義,要么大于事務的版本號:行的刪除版本號如果沒有被定義,說明該行沒有被刪除過;如果刪除版本號大于當前事務的事務號,說明該行是被該事務后面啟動的事務刪除的,由于是repeatable read隔離等級,后開始的事務對數據的影響不應該被先開始的事務看見,所以該行應該被返回.

2) INSERT 對新插入的行,行的更新版本被修改為該事務的事務號

3) DELETE 對于刪除,innodb直接把該行的被刪除版本號設置為當前的事務號,相當于標記為刪除,而不是實際刪除

4) UPDATE 在更新行的時候,innodb會把原來的行復制一份到回滾段中,并把當前的事務號作為該行的更新版本

InnoDB存儲引擎MVCC的實現策略：

在每一行數據中額外保存兩個隱藏字段：當前行創建時的版本號和刪除時的版本號(可能為空)。每個事務又有自己的版本號，這樣事務內執行CRUD操作時，就通過版本號的比較來達到數據版本控制的目的。具體做法見下面的示意圖。

MVCC缺點：

為了實現多版本，InnoDB需要維護額外的隱藏字段，以及清理不需要的行版本，帶來額外開銷。

驗證(同時開兩個終端，左邊的為事物A，右邊的為事物B;表數據為空)

一，事物級別為 RC

1.事物A插入(更新)，事物B讀取

按操作步驟執行：

我們可以得出結論

1)當事物A插入數據沒有提交的時候，事物B沒有查到數據(避免臟讀)

2)當事物A提交事物后，事物B可以查到數據(同一個事物里邊查兩次結果不一致；不可重復讀)

2，A事物更新，B事物也更新(刪除)。

當事物A更新數據的時候，對操作行加排它鎖。事物B更新此條數據的時需要等事物A提交或回滾之后才可以執行。所以是否可重復讀對結果不會有影響，都需要等待事物A執行結束之后，事物B才會執行。

二，事物級別為 RR

1.事物A插入，事物B讀取

我們可以得出結論

1)當事物A插入數據沒有提交的時候，事物B沒有查到數據(避免臟讀)

2)當事物A提交事物后，事物B還是沒有數據(同一個事物里邊查兩次結果一致；可重復讀)

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的mysql innodb 事务_Mysql InnoDB事务的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。