注：內容有點干，但希望你可以耐心地看完。回頭我寫一篇實操的文章幫助理解。

開發(fā)工作中我們會使用到事務，那你們知道事務又分哪幾種嗎？

以及不同事務隔離的加鎖實現(xiàn)原理是什么？

一、首先什么是事務？

事務是應用程序中一系列嚴密的操作，所有操作必須成功完成，否則在每個操作中所作的所有更改都會被撤消。也就是事務具有原子性，一個事務中的一系列的操作要么全部成功，要么一個都不做。

事務的結束有兩種，當事務中的所有步驟全部成功執(zhí)行時，事務提交。如果其中一個步驟失敗，將發(fā)生回滾操作，撤消事務開始時的所有操作。

二、事務的ACID

事務具有四個特征：原子性（ Atomicity ）、一致性（ Consistency ）、隔離性（ Isolation ）和持續(xù)性（ Durability ）。這四個特性簡稱為 ACID 特性。

1 、原子性。事務是數(shù)據(jù)庫的邏輯工作單位，事務中包含的各操作要么都做，要么都不做。

2 、一致性。事務執(zhí)行的結果必須是使數(shù)據(jù)庫從一個一致性狀態(tài)變到另一個一致性狀態(tài)。因此當數(shù)據(jù)庫只包含成功事務提交的結果時，就說數(shù)據(jù)庫處于一致性狀態(tài)。如果數(shù)據(jù)庫系統(tǒng)運行中發(fā)生故障，有些事務尚未完成就被迫中斷，這些未完成事務對數(shù)據(jù)庫所做的修改有一部分已寫入物理數(shù)據(jù)庫，這時數(shù)據(jù)庫就處于一種不正確的狀態(tài)，或者說是不一致的狀態(tài)。

3 、隔離性。一個事務的執(zhí)行不能被其它事務干擾。即一個事務內部的操作及使用的數(shù)據(jù)對其它并發(fā)事務是隔離的，并發(fā)執(zhí)行的各個事務之間不能互相干擾。

4 、持續(xù)性。也稱永久性，指一個事務一旦提交，它對數(shù)據(jù)庫中的數(shù)據(jù)的改變就應該是永久性的。接下來的其它操作或故障不應該對其執(zhí)行結果有任何影響。

三、MySQL的四種隔離級別

SQL標準定義了4類隔離級別，包括了一些具體規(guī)則，用來限定事務內外的哪些改變是可見的，哪些是不可見的。低級別的隔離級一般支持更高的并發(fā)處理，并擁有更低的系統(tǒng)開銷。

Read Uncommitted（讀取未提交內容）

在該隔離級別，所有事務都可以看到其他未提交事務的執(zhí)行結果。本隔離級別很少用于實際應用，因為它的性能也不比其他級別好多少。讀取未提交的數(shù)據(jù)，也被稱之為臟讀（Dirty Read）。

Read Committed（讀取提交內容）

這是大多數(shù)數(shù)據(jù)庫系統(tǒng)的默認隔離級別（但不是MySQL默認的）。它滿足了隔離的簡單定義：一個事務只能看見已經(jīng)提交事務所做的改變。這種隔離級別也支持所謂的不可重復讀（Nonrepeatable Read），因為同一事務的其他實例在該實例處理期間可能會有新的commit，所以同一select可能返回不同結果。

Repeatable Read（可重讀）

這是MySQL的默認事務隔離級別，它確保同一事務的多個實例在并發(fā)讀取數(shù)據(jù)時，會看到同樣的數(shù)據(jù)行。不過理論上，這會導致另一個棘手的問題：幻讀 （Phantom Read）。簡單的說，幻讀指當用戶讀取某一范圍的數(shù)據(jù)行時，另一個事務又在該范圍內插入了新行，當用戶再讀取該范圍的數(shù)據(jù)行時，會發(fā)現(xiàn)有新的“幻影” 行。InnoDB和Falcon存儲引擎通過多版本并發(fā)控制（MVCC，Multiversion Concurrency Control）機制解決了該問題。

Serializable（可串行化）

這是最高的隔離級別，它通過強制事務排序，使之不可能相互沖突，從而解決幻讀問題。簡言之，它是在每個讀的數(shù)據(jù)行上加上共享鎖。在這個級別，可能導致大量的超時現(xiàn)象和鎖競爭。

這四種隔離級別采取不同的鎖類型來實現(xiàn)，若讀取的是同一個數(shù)據(jù)的話，就容易發(fā)生問題。

臟讀(Drity Read)：某個事務已更新一份數(shù)據(jù)，另一個事務在此時讀取了同一份數(shù)據(jù)，由于某些原因，前一個RollBack了操作，則后一個事務所讀取的數(shù)據(jù)就會是不正確的。

不可重復讀(Non-repeatable read)：在一個事務的兩次查詢之中數(shù)據(jù)不一致，這可能是兩次查詢過程中間插入了一個事務更新的原有的數(shù)據(jù)。

幻讀(Phantom Read)：在一個事務的兩次查詢中數(shù)據(jù)筆數(shù)不一致，例如有一個事務查詢了幾列(Row)數(shù)據(jù)，而另一個事務卻在此時插入了新的幾列數(shù)據(jù)，先前的事務在接下來的查詢中，就會發(fā)現(xiàn)有幾列數(shù)據(jù)是它先前所沒有的。

在MySQL中，實現(xiàn)了這四種隔離級別，分別有可能產(chǎn)生問題如下所示：

四、事務隔離的原理是什么？

我們都知道事務的幾種性質，數(shù)據(jù)庫為了維護這些性質，尤其是一致性和隔離性，一般使用加鎖這種方式。同時數(shù)據(jù)庫又是個高并發(fā)的應用，同一時間會有大量的并發(fā)訪問，如果加鎖過度，會極大的降低并發(fā)處理能力。所以對于加鎖的處理，可以說就是數(shù)據(jù)庫對于事務處理的精髓所在。這里通過分析MySQL中InnoDB引擎的加鎖機制，來拋磚引玉，讓我們更好的理解，在事務處理中數(shù)據(jù)庫到底做了什么。

4.1、一次封鎖or兩段鎖？

因為有大量的并發(fā)訪問，為了預防死鎖，一般應用中推薦使用一次封鎖法，就是在方法的開始階段，已經(jīng)預先知道會用到哪些數(shù)據(jù)，然后全部鎖住，在方法運行之后，再全部解鎖。這種方式可以有效的避免循環(huán)死鎖，但在數(shù)據(jù)庫中卻不適用，因為在事務開始階段，數(shù)據(jù)庫并不知道會用到哪些數(shù)據(jù)。

數(shù)據(jù)庫遵循的是兩段鎖協(xié)議，將事務分成兩個階段，加鎖階段和解鎖階段（所以叫兩段鎖）。

加鎖階段：在該階段可以進行加鎖操作。在對任何數(shù)據(jù)進行讀操作之前要申請并獲得S鎖（共享鎖，其它事務可以繼續(xù)加共享鎖，但不能加排它鎖），在進行寫操作之前要申請并獲得X鎖（排它鎖，其它事務不能再獲得任何鎖）。加鎖不成功，則事務進入等待狀態(tài)，直到加鎖成功才繼續(xù)執(zhí)行。

解鎖階段：當事務釋放了一個封鎖以后，事務進入解鎖階段，在該階段只能進行解鎖操作不能再進行加鎖操作。

事務? ? ? ? ? ? ? ? 加鎖/解鎖處理

begin；

insert into test .....? ? # 加insert對應的鎖

update test set...? ? ? # 加update對應的鎖

delete from test ....? # 加delete對應的鎖

commit;? ? ? ? ? ? ? ? ? ? # 事務提交時，同時釋放insert、update、delete對應的鎖

這種方式雖然無法避免死鎖，但是兩段鎖協(xié)議可以保證事務的并發(fā)調度是串行化（串行化很重要，尤其是在數(shù)據(jù)恢復和備份的時候）的。

4.2、事務中的加鎖方式

在數(shù)據(jù)庫操作中，為了有效保證并發(fā)讀取數(shù)據(jù)的正確性，提出的事務隔離級別。我們的數(shù)據(jù)庫鎖，也是為了構建這些隔離級別存在的。

我們在前面已經(jīng)介紹了MySQL的四種隔離級別：

未提交讀(Read Uncommitted)：允許臟讀，也就是可能讀取到其他會話中未提交事務修改的數(shù)據(jù)。

提交讀(Read Committed)：只能讀取到已經(jīng)提交的數(shù)據(jù)。Oracle等多數(shù)數(shù)據(jù)庫默認都是該級別 (不重復讀)。

可重復讀(Repeated Read)：可重復讀。在同一個事務內的查詢都是事務開始時刻一致的，InnoDB默認級別。在SQL標準中，該隔離級別消除了不可重復讀，但是還存在幻象讀。

串行讀(Serializable)：完全串行化的讀，每次讀都需要獲得表級共享鎖，讀寫相互都會阻塞。

Read UnCommitted（讀取未提交內容）

Read Uncommitted這種級別，數(shù)據(jù)庫一般都不會用，而且任何操作都不會加鎖，這里就不討論了。

MySQL中鎖的種類：

MySQL中鎖的種類很多，有常見的表鎖和行鎖，也有新加入的Metadata Lock等等,表鎖是對一整張表加鎖，雖然可分為讀鎖和寫鎖，但畢竟是鎖住整張表，會導致并發(fā)能力下降，一般是做ddl處理時使用。

行鎖則是鎖住數(shù)據(jù)行，這種加鎖方法比較復雜，但是由于只鎖住有限的數(shù)據(jù)，對于其它數(shù)據(jù)不加限制，所以并發(fā)能力強，MySQL一般都是用行鎖來處理并發(fā)事務。這里主要討論的也就是行鎖。

Read Committed（讀取提交內容）

在RC級別中，數(shù)據(jù)的讀取都是不加鎖的，但是數(shù)據(jù)的寫入、修改和刪除是需要加鎖的。這種隔離級別也支持所謂的不可重復讀（Nonrepeatable Read）。

Repeatable Read（可重讀）

這是MySQL中InnoDB默認的隔離級別。我們姑且分“讀”和“寫”兩個模塊來講解。

讀（快照讀）

讀就是可重讀，可重讀這個概念是一事務的多個實例在并發(fā)讀取數(shù)據(jù)時。我們前面已經(jīng)講過“理論上，這會導致另一個棘手的問題：幻讀 （Phantom Read）”。

講到這里，我們先來好好地說明下不可重復讀和幻讀的區(qū)別：

很多人容易搞混不可重復讀和幻讀，確實這兩者有些相似。但不可重復讀重點在于update和delete，而幻讀的重點在于insert。

如果使用鎖機制來實現(xiàn)這兩種隔離級別，在可重復讀中，該sql第一次讀取到數(shù)據(jù)后，就將這些數(shù)據(jù)加鎖，其它事務無法修改這些數(shù)據(jù)，就可以實現(xiàn)可重復讀了。但這種方法卻無法鎖住insert的數(shù)據(jù)，所以當事務A先前讀取了數(shù)據(jù)，或者修改了全部數(shù)據(jù)，事務B還是可以insert數(shù)據(jù)提交，這時事務A就會發(fā)現(xiàn)莫名其妙多了一條之前沒有的數(shù)據(jù)，這就是幻讀，不能通過行鎖來避免。需要Serializable隔離級別 ，讀用讀鎖，寫用寫鎖，讀鎖和寫鎖互斥，這么做可以有效的避免幻讀、不可重復讀、臟讀等問題，但會極大的降低數(shù)據(jù)庫的并發(fā)能力。

所以說不可重復讀和幻讀最大的區(qū)別，就在于如何通過鎖機制來解決他們產(chǎn)生的問題。

MySQL、ORACLE、PostgreSQL等成熟的數(shù)據(jù)庫，出于性能考慮，都是使用了以樂觀鎖為理論基礎的MVCC（多版本并發(fā)控制）來避免這兩種問題。

這里繼續(xù)擴展下悲觀鎖和樂觀鎖的知識。

悲觀鎖：

正如其名，它指的是對數(shù)據(jù)被外界（包括本系統(tǒng)當前的其他事務，以及來自外部系統(tǒng)的事務處理）修改持保守態(tài)度，因此，在整個數(shù)據(jù)處理過程中，將數(shù)據(jù)處于鎖定狀態(tài)。悲觀鎖的實現(xiàn)，往往依靠數(shù)據(jù)庫提供的鎖機制（也只有數(shù)據(jù)庫層提供的鎖機制才能真正保證數(shù)據(jù)訪問的排他性，否則，即使在本系統(tǒng)中實現(xiàn)了加鎖機制，也無法保證外部系統(tǒng)不會修改數(shù)據(jù)）。

在悲觀鎖的情況下，為了保證事務的隔離性，就需要一致性鎖定讀。讀取數(shù)據(jù)時給加鎖，其它事務無法修改這些數(shù)據(jù)。修改刪除數(shù)據(jù)時也要加鎖，其它事務無法讀取這些數(shù)據(jù)。

樂觀鎖：

相對悲觀鎖而言，樂觀鎖機制采取了更加寬松的加鎖機制。悲觀鎖大多數(shù)情況下依靠數(shù)據(jù)庫的鎖機制實現(xiàn)，以保證操作最大程度的獨占性。但隨之而來的就是數(shù)據(jù)庫性能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受。

而樂觀鎖機制在一定程度上解決了這個問題。樂觀鎖，大多是基于數(shù)據(jù)版本（ Version ）記錄機制實現(xiàn)。何謂數(shù)據(jù)版本？即為數(shù)據(jù)增加一個版本標識，在基于數(shù)據(jù)庫表的版本解決方案中，一般是通過為數(shù)據(jù)庫表增加一個 “version” 字段來實現(xiàn)。讀取出數(shù)據(jù)時，將此版本號一同讀出，之后更新時，對此版本號加一。此時，將提交數(shù)據(jù)的版本數(shù)據(jù)與數(shù)據(jù)庫表對應記錄的當前版本信息進行比對，如果提交的數(shù)據(jù)版本號大于數(shù)據(jù)庫表當前版本號，則予以更新，否則認為是過期數(shù)據(jù)。

要說明的是，MVCC的實現(xiàn)沒有固定的規(guī)范，每個數(shù)據(jù)庫都會有不同的實現(xiàn)方式，這里討論的是InnoDB的MVCC。

接下來講解MVCC在MySQL的InnoDB中的實現(xiàn)：

在InnoDB中，會在每行數(shù)據(jù)后添加兩個額外的隱藏的值來實現(xiàn)MVCC，這兩個值一個記錄這行數(shù)據(jù)何時被創(chuàng)建，另外一個記錄這行數(shù)據(jù)何時過期（或者被刪除）。 在實際操作中，存儲的并不是時間，而是事務的版本號，每開啟一個新事務，事務的版本號就會遞增。 在可重讀Repeatable reads事務隔離級別下：

SELECT時，讀取創(chuàng)建版本號<=當前事務版本號，刪除版本號為空或>當前事務版本號。

INSERT時，保存當前事務版本號為行的創(chuàng)建版本號。

DELETE時，保存當前事務版本號為行的刪除版本號。

UPDATE時，插入一條新紀錄，保存當前事務版本號為行創(chuàng)建版本號，同時保存當前事務版本號到原來刪除的行。

通過MVCC，雖然每行記錄都需要額外的存儲空間，更多的行檢查工作以及一些額外的維護工作，但可以減少鎖的使用，大多數(shù)讀操作都不用加鎖，讀數(shù)據(jù)操作很簡單，性能很好，并且也能保證只會讀取到符合標準的行，也只鎖住必要行。

注：“讀”與“讀”的區(qū)別。

事務的隔離級別其實都是對于讀數(shù)據(jù)的定義，但到了這里，就被拆成了讀和寫兩個模塊來講解。這主要是因為MySQL中的讀，和事務隔離級別中的讀，是不一樣的。

我們且看，在RR級別中，通過MVCC機制，雖然讓數(shù)據(jù)變得可重復讀，但我們讀到的數(shù)據(jù)可能是歷史數(shù)據(jù)，是不及時的數(shù)據(jù)，不是數(shù)據(jù)庫當前的數(shù)據(jù)！這在一些對于數(shù)據(jù)的時效特別敏感的業(yè)務中，就很可能出問題。

對于這種讀取歷史數(shù)據(jù)的方式，我們叫它快照讀 (snapshot read)，而讀取數(shù)據(jù)庫當前版本數(shù)據(jù)的方式，叫當前讀 (current read)。很顯然，在MVCC中：

快照讀：就是select

select * from table ....;

當前讀：特殊的讀操作，插入/更新/刪除操作，屬于當前讀，處理的都是當前的數(shù)據(jù)，需要加鎖。

select * from table where ? lock in share mode;

select * from table where ? for update;

insert;

update ;

delete;

事務的隔離級別實際上都是定義了當前讀的級別，MySQL為了減少鎖處理（包括等待其它鎖）的時間，提升并發(fā)能力，引入了快照讀的概念，使得select不用加鎖。而update、insert這些“當前讀”，就需要另外的模塊來解決了。

因為更新數(shù)據(jù)、插入數(shù)據(jù)是針對當前數(shù)據(jù)的，所以不能以快照的歷史數(shù)據(jù)為參考，此處就是這個意思。

寫（"當前讀"）

事務的隔離級別中雖然只定義了讀數(shù)據(jù)的要求，實際上這也可以說是寫數(shù)據(jù)的要求。上文的“讀”，實際是講的快照讀，而這里說的“寫”就是當前讀了。

為了解決當前讀中的幻讀問題，MySQL事務使用了Next-Key鎖。

Next-Key鎖是行鎖和GAP（間隙鎖）的合并，行鎖上文已經(jīng)介紹了，接下來說下GAP間隙鎖。

行鎖可以防止不同事務版本的數(shù)據(jù)修改提交時造成數(shù)據(jù)沖突的情況。但如何避免別的事務插入數(shù)據(jù)就成了問題。行鎖防止別的事務修改或刪除，GAP鎖防止別的事務新增，行鎖和GAP鎖結合形成的的Next-Key鎖共同解決了RR級別在寫數(shù)據(jù)時的幻讀問題。

Serializable

這個級別很簡單，讀加共享鎖，寫加排他鎖，讀寫互斥。使用的悲觀鎖的理論，實現(xiàn)簡單，數(shù)據(jù)更加安全，但是并發(fā)能力非常差。如果你的業(yè)務并發(fā)的特別少或者沒有并發(fā)，同時又要求數(shù)據(jù)及時可靠的話，可以使用這種模式。

這里需要注意改變一個觀念，不要看到select就說不會加鎖了，在Serializable這個級別，還是會加鎖的。