注：內容有點干，但希望你可以耐心地看完。回頭我寫一篇實操的文章幫助理解。 > 開發工作中我們會使用到事務，那你們知道事務又分哪幾種嗎？ > > 以及不同事務隔離的加鎖實現原理是什么？ **一、首先什么是事務？** 事務是應用程序中一系列嚴密的操作，所有操作必須成功完成，否則在每個操作中所作的所有更改都會被撤消。也就是事務具有原子性，一個事務中的一系列的操作要么全部成功，要么一個都不做。 事務的結束有兩種，當事務中的所有步驟全部成功執行時，事務提交。如果其中一個步驟失敗，將發生回滾操作，撤消事務開始時的所有操作。 **二、事務的ACID** 事務具有四個特征：原子性（ Atomicity ）、一致性（ Consistency ）、隔離性（ Isolation ）和持續性（ Durability ）。這四個特性簡稱為 ACID 特性。 1 、原子性。事務是數據庫的邏輯工作單位，事務中包含的各操作要么都做，要么都不做。 2 、一致性。事務執行的結果必須是使數據庫從一個一致性狀態變到另一個一致性狀態。因此當數據庫只包含成功事務提交的結果時，就說數據庫處于一致性狀態。如果數據庫系統運行中發生故障，有些事務尚未完成就被迫中斷，這些未完成事務對數據庫所做的修改有一部分已寫入物理數據庫，這時數據庫就處于一種不正確的狀態，或者說是不一致的狀態。 3 、隔離性。一個事務的執行不能被其它事務干擾。即一個事務內部的操作及使用的數據對其它并發事務是隔離的，并發執行的各個事務之間不能互相干擾。 4 、持續性。也稱永久性，指一個事務一旦提交，它對數據庫中的數據的改變就應該是永久性的。接下來的其它操作或故障不應該對其執行結果有任何影響。 **三、MySQL的四種隔離級別** SQL標準定義了4類隔離級別，包括了一些具體規則，用來限定事務內外的哪些改變是可見的，哪些是不可見的。低級別的隔離級一般支持更高的并發處理，并擁有更低的系統開銷。 **Read Uncommitted（讀取未提交內容）** 在該隔離級別，所有事務都可以看到其他未提交事務的執行結果。本隔離級別很少用于實際應用，因為它的性能也不比其他級別好多少。讀取未提交的數據，也被稱之為臟讀（Dirty Read）。 **Read Committed（讀取提交內容）** 這是大多數數據庫系統的默認隔離級別（但不是MySQL默認的）。它滿足了隔離的簡單定義：一個事務只能看見已經提交事務所做的改變。這種隔離級別也支持所謂的不可重復讀（Nonrepeatable Read），因為同一事務的其他實例在該實例處理期間可能會有新的commit，所以同一select可能返回不同結果。 **Repeatable Read（可重讀）** 這是MySQL的默認事務隔離級別，它確保同一事務的多個實例在并發讀取數據時，會看到同樣的數據行。不過理論上，這會導致另一個棘手的問題：幻讀 （Phantom Read）。簡單的說，幻讀指當用戶讀取某一范圍的數據行時，另一個事務又在該范圍內插入了新行，當用戶再讀取該范圍的數據行時，會發現有新的“幻影” 行。InnoDB和Falcon存儲引擎通過多版本并發控制（MVCC，Multiversion Concurrency Control）機制解決了該問題。 **Serializable（可串行化）** 這是最高的隔離級別，它通過強制事務排序，使之不可能相互沖突，從而解決幻讀問題。簡言之，它是在每個讀的數據行上加上共享鎖。在這個級別，可能導致大量的超時現象和鎖競爭。 這四種隔離級別采取不同的鎖類型來實現，若讀取的是同一個數據的話，就容易發生問題。 臟讀(Drity Read)：某個事務已更新一份數據，另一個事務在此時讀取了同一份數據，由于某些原因，前一個RollBack了操作，則后一個事務所讀取的數據就會是不正確的。 不可重復讀(Non-repeatable read)：在一個事務的兩次查詢之中數據不一致，這可能是兩次查詢過程中間插入了一個事務更新的原有的數據。 幻讀(Phantom Read)：在一個事務的兩次查詢中數據筆數不一致，例如有一個事務查詢了幾列(Row)數據，而另一個事務卻在此時插入了新的幾列數據，先前的事務在接下來的查詢中，就會發現有幾列數據是它先前所沒有的。 在MySQL中，實現了這四種隔離級別，分別有可能產生問題如下所示：  **四****、事務隔離的原理是什么？** 我們都知道事務的幾種性質，數據庫為了維護這些性質，尤其是一致性和隔離性，一般使用加鎖這種方式。同時數據庫又是個高并發的應用，同一時間會有大量的并發訪問，如果加鎖過度，會極大的降低并發處理能力。所以對于加鎖的處理，可以說就是數據庫對于事務處理的精髓所在。這里通過分析MySQL中InnoDB引擎的加鎖機制，來拋磚引玉，讓我們更好的理解，在事務處理中數據庫到底做了什么。 **4.1、一次封鎖or兩段鎖？** 因為有大量的并發訪問，為了預防死鎖，一般應用中推薦使用一次封鎖法，就是在方法的開始階段，已經預先知道會用到哪些數據，然后全部鎖住，在方法運行之后，再全部解鎖。這種方式可以有效的避免循環死鎖，但在數據庫中卻不適用，因為在事務開始階段，數據庫并不知道會用到哪些數據。 數據庫遵循的是兩段鎖協議，將事務分成兩個階段，加鎖階段和解鎖階段（所以叫兩段鎖）。 加鎖階段：在該階段可以進行加鎖操作。在對任何數據進行讀操作之前要申請并獲得S鎖（共享鎖，其它事務可以繼續加共享鎖，但不能加排它鎖），在進行寫操作之前要申請并獲得X鎖（排它鎖，其它事務不能再獲得任何鎖）。加鎖不成功，則事務進入等待狀態，直到加鎖成功才繼續執行。 解鎖階段：當事務釋放了一個封鎖以后，事務進入解鎖階段，在該階段只能進行解鎖操作不能再進行加鎖操作。 > **事務? ? ? ? ? ? ? ? 加鎖/解鎖處理** > > begin； > > insert into test .....? ? # 加insert對應的鎖 > > update test set...? ? ? # 加update對應的鎖 > > delete from test ....? # 加delete對應的鎖 > > commit;? ? ? ? ? ? ? ? ? ? # 事務提交時，同時釋放insert、update、delete對應的鎖 這種方式雖然無法避免死鎖，但是兩段鎖協議可以保證事務的并發調度是串行化（串行化很重要，尤其是在數據恢復和備份的時候）的。 **4.2、事務中的加鎖方式** 在數據庫操作中，為了有效保證并發讀取數據的正確性，提出的事務隔離級別。我們的數據庫鎖，也是為了構建這些隔離級別存在的。 我們在前面已經介紹了MySQL的四種隔離級別： > 未提交讀(Read Uncommitted)：允許臟讀，也就是可能讀取到其他會話中未提交事務修改的數據。 > > 提交讀(Read Committed)：只能讀取到已經提交的數據。Oracle等多數數據庫默認都是該級別 (不重復讀)。 > > 可重復讀(Repeated Read)：可重復讀。在同一個事務內的查詢都是事務開始時刻一致的，InnoDB默認級別。在SQL標準中，該隔離級別消除了不可重復讀，但是還存在幻象讀。 > > 串行讀(Serializable)：完全串行化的讀，每次讀都需要獲得表級共享鎖，讀寫相互都會阻塞。 **Read UnCommitted（讀取未提交內容）** Read Uncommitted這種級別，數據庫一般都不會用，而且任何操作都不會加鎖，這里就不討論了。 > MySQL中鎖的種類： > > MySQL中鎖的種類很多，有常見的表鎖和行鎖，也有新加入的Metadata Lock等等,表鎖是對一整張表加鎖，雖然可分為讀鎖和寫鎖，但畢竟是鎖住整張表，會導致并發能力下降，一般是做ddl處理時使用。 > > 行鎖則是鎖住數據行，這種加鎖方法比較復雜，但是由于只鎖住有限的數據，對于其它數據不加限制，所以并發能力強，MySQL一般都是用行鎖來處理并發事務。這里主要討論的也就是行鎖。 **Read Committed（讀取提交內容）** 在RC級別中，數據的讀取都是不加鎖的，但是數據的寫入、修改和刪除是需要加鎖的。這種隔離級別也支持所謂的不可重復讀（Nonrepeatable Read）。 **Repeatable Read（可重讀）** 這是MySQL中InnoDB默認的隔離級別。我們姑且分“讀”和“寫”兩個模塊來講解。 **讀（快照讀）** 讀就是可重讀，可重讀這個概念是一事務的多個實例在并發讀取數據時。我們前面已經講過“理論上，這會導致另一個棘手的問題：幻讀 （Phantom Read）”。 講到這里，我們先來好好地說明下不可重復讀和幻讀的區別： > 很多人容易搞混不可重復讀和幻讀，確實這兩者有些相似。但不可重復讀重點在于update和delete，而幻讀的重點在于insert。 > > 如果使用鎖機制來實現這兩種隔離級別，在可重復讀中，該sql第一次讀取到數據后，就將這些數據加鎖，其它事務無法修改這些數據，就可以實現可重復讀了。但這種方法卻無法鎖住insert的數據，所以當事務A先前讀取了數據，或者修改了全部數據，事務B還是可以insert數據提交，這時事務A就會發現莫名其妙多了一條之前沒有的數據，這就是幻讀，不能通過行鎖來避免。需要Serializable隔離級別 ，讀用讀鎖，寫用寫鎖，讀鎖和寫鎖互斥，這么做可以有效的避免幻讀、不可重復讀、臟讀等問題，但會極大的降低數據庫的并發能力。 > > 所以說不可重復讀和幻讀最大的區別，就在于如何通過鎖機制來解決他們產生的問題。 > > MySQL、ORACLE、PostgreSQL等成熟的數據庫，出于性能考慮，都是使用了以樂觀鎖為理論基礎的MVCC（多版本并發控制）來避免這兩種問題。 這里繼續擴展下悲觀鎖和樂觀鎖的知識。 > 悲觀鎖： > > 正如其名，它指的是對數據被外界（包括本系統當前的其他事務，以及來自外部系統的事務處理）修改持保守態度，因此，在整個數據處理過程中，將數據處于鎖定狀態。悲觀鎖的實現，往往依靠數據庫提供的鎖機制（也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無法保證外部系統不會修改數據）。 > > 在悲觀鎖的情況下，為了保證事務的隔離性，就需要一致性鎖定讀。讀取數據時給加鎖，其它事務無法修改這些數據。修改刪除數據時也要加鎖，其它事務無法讀取這些數據。 > > 樂觀鎖： > > 相對悲觀鎖而言，樂觀鎖機制采取了更加寬松的加鎖機制。悲觀鎖大多數情況下依靠數據庫的鎖機制實現，以保證操作最大程度的獨占性。但隨之而來的就是數據庫性能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受。 > > 而樂觀鎖機制在一定程度上解決了這個問題。樂觀鎖，大多是基于數據版本（ Version ）記錄機制實現。何謂數據版本？即為數據增加一個版本標識，在基于數據庫表的版本解決方案中，一般是通過為數據庫表增加一個 “version” 字段來實現。讀取出數據時，將此版本號一同讀出，之后更新時，對此版本號加一。此時，將提交數據的版本數據與數據庫表對應記錄的當前版本信息進行比對，如果提交的數據版本號大于數據庫表當前版本號，則予以更新，否則認為是過期數據。 > > 要說明的是，MVCC的實現沒有固定的規范，每個數據庫都會有不同的實現方式，這里討論的是InnoDB的MVCC。 接下來講解MVCC在MySQL的InnoDB中的實現： > 在InnoDB中，會在每行數據后添加兩個額外的隱藏的值來實現MVCC，這兩個值一個記錄這行數據何時被創建，另外一個記錄這行數據何時過期（或者被刪除）。 在實際操作中，存儲的并不是時間，而是事務的版本號，每開啟一個新事務，事務的版本號就會遞增。 在可重讀Repeatable reads事務隔離級別下： > > SELECT時，讀取創建版本號當前事務版本號。 > > INSERT時，保存當前事務版本號為行的創建版本號。 > > DELETE時，保存當前事務版本號為行的刪除版本號。 > > UPDATE時，插入一條新紀錄，保存當前事務版本號為行創建版本號，同時保存當前事務版本號到原來刪除的行。 > > 通過MVCC，雖然每行記錄都需要額外的存儲空間，更多的行檢查工作以及一些額外的維護工作，但可以減少鎖的使用，大多數讀操作都不用加鎖，讀數據操作很簡單，性能很好，并且也能保證只會讀取到符合標準的行，也只鎖住必要行。 注：“讀”與“讀”的區別。 事務的隔離級別其實都是對于讀數據的定義，但到了這里，就被拆成了讀和寫兩個模塊來講解。這主要是因為MySQL中的讀，和事務隔離級別中的讀，是不一樣的。 我們且看，在RR級別中，通過MVCC機制，雖然讓數據變得可重復讀，但我們讀到的數據可能是歷史數據，是不及時的數據，不是數據庫當前的數據！這在一些對于數據的時效特別敏感的業務中，就很可能出問題。 對于這種讀取歷史數據的方式，我們叫它快照讀 (snapshot read)，而讀取數據庫當前版本數據的方式，叫當前讀 (current read)。很顯然，在MVCC中： > 快照讀：就是select > > select \* from table ....; > > 當前讀：特殊的讀操作，插入/更新/刪除操作，屬于當前讀，處理的都是當前的數據，需要加鎖。 > > select \* from table where ? lock in share mode; > > select \* from table where ? for update; > > insert; > > update ; > > delete; 事務的隔離級別實際上都是定義了當前讀的級別，MySQL為了減少鎖處理（包括等待其它鎖）的時間，提升并發能力，引入了快照讀的概念，使得select不用加鎖。而update、insert這些“當前讀”，就需要另外的模塊來解決了。 **因為更新數據、插入數據是針對當前數據的，所以不能以快照的歷史數據為參考，此處就是這個意思。** **寫（"當前讀"）** 事務的隔離級別中雖然只定義了讀數據的要求，實際上這也可以說是寫數據的要求。上文的“讀”，實際是講的快照讀，而這里說的“寫”就是當前讀了。 為了解決當前讀中的幻讀問題，MySQL事務使用了Next-Key鎖。 Next-Key鎖是行鎖和GAP（間隙鎖）的合并，行鎖上文已經介紹了，接下來說下GAP間隙鎖。 行鎖可以防止不同事務版本的數據修改提交時造成數據沖突的情況。但如何避免別的事務插入數據就成了問題。行鎖防止別的事務修改或刪除，GAP鎖防止別的事務新增，行鎖和GAP鎖結合形成的的Next-Key鎖共同解決了RR級別在寫數據時的幻讀問題。 **Serializable** 這個級別很簡單，讀加共享鎖，寫加排他鎖，讀寫互斥。使用的悲觀鎖的理論，實現簡單，數據更加安全，但是并發能力非常差。如果你的業務并發的特別少或者沒有并發，同時又要求數據及時可靠的話，可以使用這種模式。 這里需要注意改變一個觀念，不要看到select就說不會加鎖了，在Serializable這個級別，還是會加鎖的。