1.事務的ACID屬性

事務(Database Transaction) ，是指作為單個邏輯工作單元執行的一系列操作。事務處理可以確保除非事務性單元內的所有操作都成功完成，否則不會永久更新面向數據的資源。通過將一組相關操作組合為一個要么全部成功要么全部失敗的單元，可以簡化錯誤恢復并使應用程序更加可靠。一個邏輯工作單元要成為事務，必須滿足所謂的ACID(原子性、一致性、隔離性和持久性)屬性。

原子性(atomic)，事務必須是原子工作單元；對于其數據修改，要么全都執行，要么全都不執行

一致性(consistent)，事務在完成時，必須使所有的數據都保持一致狀態。

隔離性(insulation)，由并發事務所作的修改必須與任何其它并發事務所作的修改隔離。

持久性(Duration)，事務完成之后，它對于系統的影響是永久性的。

2.mysql更新丟失

a.第一類丟失更新(lost update)： 在完全未隔離事務的情況下，兩個事物更新同一條數據資源，某一事物異常終止，回滾造成第一個完成的更新也同時丟失。

b.第二類丟失更新(second lost updates)：是不可重復讀的特殊情況，如果兩個事務都讀取同一行，然后兩個都進行寫操作，并提交，第一個事務所做的改變就會丟失。

c.臟讀(dirty read)：如果第二個事務查詢到第一個事務還未提交的更新數據，形成臟讀。

d.幻讀(phantom read)：一個事務執行兩次查詢，第二次結果集包含第一次中沒有或者某些行已被刪除，造成兩次結果不一致，只是另一個事務在這兩次查詢中間插入或者刪除了數據造成的。

e.不可重復讀(unrepeated read)：一個事務兩次讀取同一行數據，結果得到不同狀態結果，如中間正好另一個事務更新了該數據，兩次結果相異，不可信任。

3.事務的四種隔離等級，按照安全性由高到低分別為

a. Serializable 串行化

b. Repeatable Read 可重復讀

c. Read Commited 可讀已提交

d. Read Uncommited 可讀未提交

隔離級別臟讀不可重復讀幻讀第一類丟失更新第二類丟失更新

READ UNCOMMITED

允許

允許

允許

不允許

允許

READ COMMITTED

不允許

允許

允許

不允許

允許

REPEATABLE READ

不允許

不允許

允許

不允許

不允許

SERIALIZABLE

不允許

不允許

不允許

不允許

不允許

4.悲觀鎖和樂觀鎖

a.悲觀鎖：大多數情況下依靠數據庫的鎖機制實現，以保證操作最大程度的獨占性。但隨之而來的就是數據庫性能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受。

b.樂觀鎖：為了避免悲觀鎖的性能問題，大多是基于數據版本(Version)記錄機制實現。何謂數據版本？即為數據增加一個版本標識，在基于數據庫表的版本解決方案中，一般是通過為數據庫表增加一個"version"字段來實現。

樂觀鎖的工作原理：讀取出數據時，將此版本號一同讀出，之后更新時，對此版本號加一。此時，將提交數據的版本數據與數據庫表對應記錄的當前版本信息進行比對，如果提交的數據版本號大于數據庫表當前版本號，則予以更新，否則認為是過期數據。

5.innodb事務特性

a.innodb能檢測到死鎖，可能返回錯誤，也可能將持有最少行級排他鎖的事務進行回滾

b.innodb存儲引擎在修改表數據時，使用事務日志，用追加的方式保存修改記錄，將隨機IO方式改為了順序IO方式，提高處理速度、

c.事務默認采用自動提交，如果不是顯示開始一個事務，則每個查詢都被當做一個事務執行提交操作

6.InnoDB的事務隔離等級以及如何解決幻讀：

innodb引擎默認使用REPEATABLE READ(可重復讀)隔離級別。該隔離級別還是會產生幻讀問題。還

需要使用next-key locking技術啟動事務來避免幻讀。

具體實現是：事務A針對非唯一索引查詢時，會使用排它鎖 鎖住索引前后兩個范圍，其他事務無法在此范圍內寫入數據，這樣事務A多次查詢的記錄數都是一樣的

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

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

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

1) SELECT:如果要查詢的行被行鎖鎖定，為了提高效率會去讀取undo日志，提高了效率。如果沒有鎖定呢？根據條件查詢出結果并過濾掉deleteVersion早于當前事務的行？

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

3) DELETE:對于刪除,innodb直接把該行的被刪除版本號設置為當前的事務號,相當于標記為刪除,而不是實際刪除。innodb有一定規則來觸發真正的刪除操作

4) UPDATE:在更新行的時候,innodb會把原來的行復制一份到undo段中,并把當前的事務號作為該行的創建版本？(undo日志到底存的什么？)

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

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

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

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

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