淺談事務的隔離級別以及應用

如題，下面從四個方面來闡釋：

1.事務的隔離級別

2.髒讀、不可重讀讀、幻讀的理解

3.經常使用數據庫的默認隔離級別

4.實際項目中的應用

 

1、數據庫事務、spring事務的隔離級別：

2、那麼什麼是髒讀、不可重讀讀、幻讀呢？

髒讀（Dirty Read)

    髒讀意味着一個事務讀取了另外一個事務未提交的數據,而這個數據是有可能回滾

不可重複讀(Unrepeatable Read)

     不可重複讀意味着，在數據庫訪問中，一個事務範圍內兩個相同的查詢卻返回了不一樣數據。這是因爲查詢時系統中其餘事務修改的提交而引發的。

    例如：事務B中對某個查詢執行兩次，當第一次執行完時，事務A對其數據進行了修改。事務B中再次查詢時，數據發生了改變

 幻讀(phantom read)

  幻讀,是指當事務不是獨立執行時發生的一種現象，例如第一個事務對一個表中的數據進行了修改，這種修改涉及到表中的所有數據行。同時，第二個事務也修改這個表中的數據，這種修改是向表中插入一行新數據。那麼，之後就會發生操做第一個事務的用戶發現表中還有沒有修改的數據行，就好象發生了幻覺同樣.

3、數據庫默認的隔離級別

mysql 默認級別是Repeatable read

oracle、sql server 是 Read committed

 

4、實際項目中咱們應該怎麼作 ？

spring 中的Transactional註解提供了隔離級別的設置

一、Isolation.DEFAULT:爲數據源的默認隔離級別

二、isolation=Isolation.READ_UNCOMMITTED:未受權讀取級別

以操做同一行數據爲前提，讀事務容許其餘讀事務和寫事務，未提交的寫事務禁止其餘寫事務（但容許其餘讀事務）。此隔離級別能夠防止更新丟失，但不能防止髒讀、不可重複讀、幻讀。此隔離級別能夠經過「排他寫鎖」實現。

三、iIsolation.READ_COMMITTED:受權讀取級別

以操做同一行數據爲前提，讀事務容許其餘讀事務和寫事務，未提交的寫事務禁止其餘讀事務和寫事務。此隔離級別能夠防止更新丟失、髒讀，但不能防止不可重複讀、幻讀。此隔離級別能夠經過「瞬間共享讀鎖」和「排他寫鎖」實現。

四、iIsolation.REPEATABLE_READ:可重複讀取級別

以操做同一行數據爲前提，讀事務禁止其餘寫事務（但容許其餘讀事務），未提交的寫事務禁止其餘讀事務和寫事務。此隔離級別能夠防止更新丟失、髒讀、不可重複讀，但不能防止幻讀。此隔離級別能夠經過「共享讀鎖」和「排他寫鎖」實現。

五、iIsolation.SERIALIZABLE:序列化級別

提供嚴格的事務隔離。它要求事務序列化執行，事務只能一個接着一個地執行，不能併發執行。此隔離級別能夠防止更新丟失、髒讀、不可重複讀、幻讀。若是僅僅經過「行級鎖」是沒法實現事務序列化的，必須經過其餘機制保證新插入的數據不會被剛執行查詢操做的事務訪問到。

 

隔離級別越高，越能保證數據的完整性和一致性，可是對併發性能的影響也越大。對於多數應用程序，能夠優先考慮把數據庫系統的隔離級別設爲Read Committed。它可以避免更新丟失、髒讀，並且具備較好的併發性能。儘管它會致使不可重複讀、幻讀這些併發問題，在可能出現這類問題的個別場合，能夠由應用程序採用悲觀鎖或樂觀鎖來控制。

 

那麼什麼是樂觀鎖和悲觀鎖，如何使用？

一、悲觀鎖，正如其名，它指的是對數據被外界（包括本系統當前的其餘事務，以及來自外部系統的事務處理）修改持保守態度，所以，在整個數據處理過程當中，將數據處於鎖定狀態。悲觀鎖的實現，每每依靠數據庫提供的鎖機制（也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，不然，即便在本系統中實現了加鎖機制，也沒法保證外部系 

統不會修改數據）。

二、樂觀鎖（ Optimistic Locking ） 

相對悲觀鎖而言，樂觀鎖機制採起了更加寬鬆的加鎖機制。悲觀鎖大多數狀況下依靠數據庫的鎖機制實現，以保證操做最大程度的獨佔性。但隨之而來的就是數據庫性能的大量開銷，特別是對長事務而言，這樣的開銷每每沒法承受。

而樂觀鎖機制在必定程度上解決了這個問題。樂觀鎖，大可能是基於數據版本（ Version ）記錄機制實現。何謂數據版本？即爲數據增長一個版本標識，在基於數據庫表的版本解決方案中，通常是經過爲數據庫表增長一個 「version」 字段來實現。讀取出數據時，將此版本號一同讀出，以後更新時，對此版本號加一。此時，將提交數據的版本數據與數據庫表對應記錄的當前版本信息進行比對，若是提交的數據版本號大於數據庫表當前版本號，則予以更新，不然認爲是過時數據。