數據庫的事務隔離級別怎么理解

本篇內容主要講解“數據庫的事務隔離級別怎么理解”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“數據庫的事務隔離級別怎么理解”吧!

1. 在MVCC并發控制中，讀操作可以分成兩類：快照讀 (snapshot read)與當前讀 (current read)。快照讀，某一時刻的一致性讀，不用加鎖。當前讀，讀取的是記錄的最新版本，并且，當前讀返回的記錄，都會加上鎖，保證其他事務不會再并發修改這條記錄。

2. MySQL在RR隔離級別下，快照讀和當前讀如果在一個會話中先后出現，可能會出現幻讀。因為快照讀不加鎖，會允許新的插入，當前讀需要讀到塊的最新版本，因此快照讀和當前讀兩次操作間，就可能會出現幻讀。 

3. MySQL為實現RR隔離級別，帶來了很大的代價，引入了Next-Key Locking解決當前讀模式下的幻讀問題。Next-Key Locking可能會導致大量的DML失敗。Oracle沒有RR隔離級別，在read only級別下，Oracle沒有幻讀的問題（是快照讀的模式），在read committed級別下，快照讀、當前讀以及混合的【快照讀和當前讀】下都存在幻讀的問題。 

4. RR隔離級別，MySQL是依靠MVCC實現的可重復讀（read view），同時依靠MVCC實現快照讀下的幻讀問題，依靠Next-Key Locking實現當前讀下的幻讀問題，所以MySQL InnoDB的可重復讀并不保證避免幻讀，需要應用顯式的使用加鎖讀來保證，而這個加鎖讀使用到的機制就是next-key locks。

5. 臟讀、不可重復讀、幻讀，是一種缺陷，越往后，解決缺陷的成本越高

6. 隔離級別越高，能解決的“缺陷”越多，為什么不直接使用最高的事務隔離級別，那不就沒有缺陷了？ 因為隔離級別越高，并發性可能會越低。

7. 臟讀，解決 寫不阻塞讀的問題，提高并發性，犧牲讀一致性。現在絕大多數的主流數據庫，都是通過MVCC來解決寫不阻塞讀的問題，不是通過經典的鎖來實現。

8. 為什么會出現不可重復讀取？ 
   在經典的read commited方式下，對于讀取過的數據并不加鎖（讀取的當下加共享鎖，讀取完成后釋放共享鎖），那么再次訪問時數據可能已經被其他事務修改。

9. 如何才能做到可重復讀？ 
   老一輩的數據庫藝術家用的方式是加鎖，對讀取過的數據加鎖，就能保證每一次讀取到的數據都是一樣的，因為對讀取過的數據加鎖后，數據無法發生修改了。這也是repeatable read這個隔離級別要解決的問題，但是經典的實現可重復讀的方式會產生幻讀。現在絕大多數的主流數據庫，是通過MVCC來做到的可重復讀，不是通過加鎖。

10. 經典的可重復讀提供了一個一致性（語句級和事務級）的讀取方式，雖存在幻讀，單從一致性的角度看，并不是一個大的缺陷，如果以經典的鎖的方式去實現可重復讀，發生死鎖的概率極大，但帶來的一個（好的）副作用，解決了丟失更新的問題。

11. 按照經典的隔離級別定義，read uncommited,read commited，都不能提供一致性讀。因為當下主流數據庫都基于MVCC實現，不基于經典的鎖方式，所以都實現了在read commited級別下的語句級的一致性。經典的隔離級別下，repeatable read在語句級一致性的基礎上還做到了事務級的一致性。

12. 針對oracle的隔離級別來說，read commited級別能夠提供語句級的一致性，這個隔離級別避免不了事務級的幻讀的問題，需要read only或者最高的SERIALIZABLE級別。

13. 在一個采用共享讀鎖（而不是多版本）的數據庫中，如果啟用了REPEATABLE READ，可以避免丟失更新的問題。原因是：已被讀取的數據會在上面加一個鎖（共享讀鎖，非排它鎖），這個鎖會保證數據不能被任何其他事務修改。

14. 在可重復讀（REPEATABLE READ，簡稱RR）隔離級別下，read view是在第一個讀請求發起時創建的。在讀已提交（READ COMMITTED，簡稱RC）隔離級別下，則是在每次讀請求時都會重新創建一份read view。根據上面提到的說法，RC隔離級別下，是每次發起SELECT都會創建read view，也就是每次SELECT都能讀取到本次查詢開始時的已經commit的數據，所以才會出現不可重復讀、幻讀現象。

15. read view 判斷當前版本數據項是否可見 
    在innodb中，創建一個新事務的時候，innodb會將當前系統中的活躍事務列表（trx_sys->trx_list）創建一個副本（read view），副本中保存的是系統當前不應該被本事務看到的其他事務id列表。當用戶在這個事務中要讀取該行記錄的時候，innodb會將該行當前的版本號與該read view進行比較。 
    具體的算法如下: 
    

1. 設該行的當前事務id為trx_id_0，read view中最早的事務id為trx_id_1, 最遲的事務id為trx_id_2.

2. 如果trx_id_0< trx_id_1的話，那么表明該行記錄所在的事務已經在本次新事務創建之前就提交了，所以該行記錄的當前值是可見的。跳到步驟6.

3. 如果trx_id_0>trx_id_2的話，那么表明該行記錄所在的事務在本次新事務創建之后才開啟，所以該行記錄的當前值不可見.跳到步驟5。

4. 如果trx_id_1<=trx_id_0<=trx_id_2, 那么表明該行記錄所在事務在本次新事務創建的時候處于活動狀態，從trx_id_1到trx_id_2進行遍歷，如果trx_id_0等于他們之中的某個事務id的話，那么不可見。跳到步驟5.

5. 從該行記錄的DB_ROLL_PTR指針所指向的回滾段中取出最新的undo-log的版本號，將它賦值該trx_id_0，然后跳到步驟2.

6. 將該可見行的值返回。

需要注意的是，新建事務(當前事務)與正在內存中commit 的事務不在活躍事務鏈表中。

到此，相信大家對“數據庫的事務隔離級別怎么理解”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！