事務以及隔離級別詳解

時間 2019-11-17

原文原文鏈接

事務以及隔離級別詳解mysql

1、什麼是事務？sql

事務的原子性：通俗一點講，事務的原子性就是一件完整的事情（有可能只有一步，有可能有不少步），要麼作完，要麼不作！這一點，也就是事務最終要的一點：事物的原子性！數據庫

事務的一致性：也就是執行完事務以後，數據不會被破壞！打個比方說：若是重A帳戶抓張到B帳戶，不能由於A帳戶扣了錢，而B帳戶沒有收到錢，這個時候用戶必定很是氣憤!app

事物的隔離性：當咱們編寫了一條update語句後，提交到數據庫的時候，有可能別人對同一條數據執行了另外一個update語句（或者delete語句），這個時候若是不加控制，後果不堪設想。咱們必須保證事務實踐是隔離的。同一條數據同一個時刻，只能有一個事務在操做！不能被其餘事務所幹擾！性能

事物的持久性：很簡單了，我執行了一個事務，必須是留下「痕跡」，將結果記錄下來，不然，我執行事務幹嗎！spa

其實，這幾個基本概念，稍微捋一下，其內部邏輯很明瞭：原子性基礎，隔離是手段，持久性是結果，都是圍繞着這個結果的「一致性」這個「老大」混的！若是數據不一致，那能叫健康的系統嗎？設計

2、隔離級別事務

既然隔離性是手段，那麼若是作到隔離呢？也就是說我哪知道當有兩個事務同時進行的時候，哪一個先來哪一個後作怎麼作呢？這就是咱們給事務定義的四個級別了：it

　　Read-Uncommited：讀未提交的數據！--一個事務能夠讀取另外一個事務未提交的數據！table

　打個比方說吧：老闆給你發工資，你的工資原本是1.2萬，可是，老闆一不當心按成了1.5，這個時候該事務還沒有提交，可是你能夠讀取數據，你一看，漲了3k很happy。後來，老闆在提交前發現了這個問題，事務回滾，從新改過來了，你再去查又變回了1.2，很不爽，去找老闆.....這就是髒讀！因爲都去了未提交的數據而致使的錯誤！

Read-Commited：讀已提交！

顧名思義，只能讀取已經提交的內容！顯然，這個可以解決上一個問題。可是，又有新問題來了。若是你拿着1.2w的工資出去happy，happy完後準備付錢，

（你用手機銀行支付的時候好男人通常會上交工資卡，哎....）,這個時候系統顯示餘額是1.2w，就在這個時候，你老婆耍你的卡買了個電視，1.1w多，當系統準備扣費的時候，系統檢測你只剩下零頭了（這次檢測顯然要等老婆那邊扣款完成並提交），瞬間鬱悶了！

（注意：查餘額-->輸入金額-->查餘額-->扣款這顯然是你此次happy付款的一個事務）

這就是讀取已提交，雖然解決了髒讀問題，可是又來了一個新問題：那就是同一個事務範圍內，兩個相同的查詢卻出現了不一樣的結果！這就是不可重複讀的！由於你這個事務開啓了，可是另外一個事務仍是能夠修改事務所涉及的數據！

Repeatable-Read：可重複讀

此處的可重複讀就是解決上面的問題的，即當一個事務開始後，就不容許其餘事務對該事務涉及的那條數據進行修改了！那麼在該事務後續對該數據的查詢中就不會出現同一個事務中查詢同一條數據可是查詢結果不同了（不要理解錯了，不是能夠重複讀一條數據！）

　　ok，可重複讀的問題解決了，那麼，還有一個問題------幻讀！

仍是以你拿工資出去happy的例子老說吧！（這個比較有切身體會......）

你出去花錢，老婆有可能會拿對帳單查帳（每一次消費都會生成一條消費記錄，而後彙總）；當你某一天打算去買一臺電腦的時候，你老婆正好查你的帳，原本查着你本月只花了2k，老婆很開心，那麼她就準備打印對帳單了，此時，你正好刷卡買電腦，新增了一條消費記錄，完成後，老婆提交打印請求，打出來後，我去，一看總價花了1.2w，內心瞬間抓狂。。。感受出現了「幻覺」！這就是幻讀，針對的就是在一個事務執行時，另外一個事務插入裏另外一條記錄，致使該事務兩次查詢結果的不一致！

由此能夠看到，可重複讀針對的是對同一條數據的update，而幻讀是針對同一組數據的insert

由於重複讀只能讓該事務涉及的單條數據不能修改，而不會管其餘數據不插入！

Serializable：序列化！

那麼，序列化就是解決幻讀的！在該級別下，事務串行化順序執行，能夠避免髒讀、不可重複讀與幻讀。可是這種事務隔離級別效率低下，比較耗數據庫性能，通常不使用。

說到這裏，其實你們也都瞭解了，只又髒讀是絕對不容許的，他會破壞數據的一致性，其他的其實也就是跟具體業務相關了！因此，在mysql中，默認的事務隔離級別就是Read-Commited！

搞清楚了上面這段話，那麼之後設計系統，須要考慮那種級別的事務處理，就不是難事了！