MySQL中的事務分析是怎樣的

MySQL中的事務分析是怎樣的，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

我們都知道，計算機處理的速度非常地快，但是再快的計算機，也面臨著這樣的問題，同一個時間里面有著非常多的請求都要對統一資源發生操作。所以，在數據庫中，引入事務來解決這樣的問題。 

我們舉個簡單的例子，我在街上買了2排益力多，要支付寶轉25元給商家，這個時候會這樣操作，支付寶先檢查我的余額是否還有25元，然后從我的余額中扣取25元，然后商家的支付寶增加25元。假如我的支付寶剛好只有25元，在轉給商家的瞬間，我用另外一個手機，在拼多多上面買了一個20元的西瓜，也用支付寶支付，因為有了數據庫事務，這兩個操作并不會同時成功。

Mysql的數據庫有著4大特性，我們稱之為ACID。即原子性，一致性，隔離性，與持久性。

原子性(atomicity)一個事務必須被視為一個不可分割的最小工作單元，整個事務中的所有操作要么全部提交成功，要么全部失敗回滾，對于一個事務來說，不可能只執行其中的一部分操作，這就是事務的原子性。在上述例子中，要么我扣了25元，益力多的商家多了25元，要么我不扣錢，商家也不多錢。不會存在扣了我的錢，商家又沒收到錢的情況。那估計每天都是各種投訴跟糾紛。

一致性(consistency)數據庫總是從一個一致性的狀態轉換到另一個一致性的狀態。(在前面的例子中，一致性確保了，這25元要么在我這還沒給商家，要么已經到達商家賬戶了，不會存在這25元憑空消失的情況。)

隔離性(isolation)通常來說，一個事務所做的修改在最終提交以前，對其他事務是不可見的。(在前面的例子中，當我還在支付給小賣部賣家25元的時候，對于我另外一個在拼多多上付款的事務，是覺得我還有25元的，只有當我整個事務提交后，另外一個事務才知道我已經扣除了對應的數額。所以，我們在執行扣除的時候，同時也要判斷余額是否足夠。)

持久性(durability)一旦事務提交，則其所做的修改將永久保存到數據庫。(此時即使系統崩潰，修改的數據也不會丟失。)

實時上，如果數據庫要嚴格遵循這這個性質，勢必會造成數據庫的性能降低。所以，在InnoDB中，是有著多種不同的事務級別的。分別是讀未提交，讀已提交，可重復讀，，與串行化四種突通的級別。

讀未提交：別人改數據的事務尚未提交，我在我的事務中也能讀到。上述例子，假如拼多多的扣款是發生在我的金額已經減少25之后，但是事務還沒提交，這個時候讀取數據庫，就已經讀到數據是0了。很顯然，如果這個時候，前面的時候回滾了，那么這個讀取到的結果稱之為臟讀。

讀已提交：別人改數據的事務已經提交，我在我的事務中才能讀到。在上述例子中，如果扣減25的事務未完成，那么讀到的都是結果25。假如在后面的事務中，多次讀取余額，那么就有可能讀到25，可能讀到0，我們稱之為不可重復讀。

可重復讀：別人改數據的事務已經提交，我在我的事務中也不去讀。這種在第一次讀數據的時候，實際上就已經形成對應的視圖，后面只能讀到對應的數據。

串行：我的事務尚未提交，別人就別想改數據。這個是嚴格串行化，在上述例子中，只有前面的扣除25元完成后，才能開始后面的事務。

 

這4種隔離級別，并行性能依次降低，安全性依次提高。

關于MySQL中的事務分析是怎樣的問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。