謝邀。

首先我要指出問題中提出的各種概念非常混亂。簡單梳理下：

早期數據庫不論讀取還是寫入，都用鎖來實現。但是鎖會帶來性能的問題。人們嘗試各種優化方案。寫入和讀取的優化方式不同。

對于數據庫寫入操作，沒有特別好的辦法，因為無論如何要避免并發修改一個數據，就得靠鎖。不同的數據庫對于寫入操作都會加悲觀鎖(比如MySQL是X鎖)。為了避免X鎖帶來的性能問題，人們在合適的場合會選擇用樂觀鎖來優化。有的數據庫內建樂觀鎖，但是有的沒有(比如MySQL就沒有)，所以需要開發人員自己在數據表里加version列，自己寫業務代碼實現。順便提一句，樂觀鎖并不一定總是比悲觀鎖性能表現更好，這要看競爭的程度。如果數據訪問競爭的非常厲害，樂觀鎖只會讓CPU和IO白白浪費而已。

對于讀取，優化就是MVCC。現在主流的商業數據庫都是基于MVCC，如MySQL InnoDB和Postgres。MVCC的意思用簡單的話講就是對數據庫的任何修改的提交都不會直接覆蓋之前的數據，而是產生一個新的版本與老版本共存，使得讀取時可以完全不加鎖。這樣讀某一個數據時，事務可以根據隔離級別選擇要讀取哪個版本的數據。過程中完全不需要加鎖。

這樣，實現兩個隔離級別就非常容易：Read Committed - 一個事務讀取數據時總是讀這個數據最近一次被commit的版本

Repeatable Read - 一個事務讀取數據時總是讀取當前事務開始之前最后一次被commit的版本(所以底層實現時需要比較當前事務和數據被commit的版本號)。

舉個簡單的例子：一個事務A(txnId=100)修改了數據X，使得X=1，并且commit了

另外一個事務B(txnId=101)開始嘗試讀取X，但是還X=1。但B沒有提交。

第三個事務C(txnId=102)修改了數據X，使得X=2。并且提交了

事務B又一次讀取了X。這時如果事務B是Read Committed。那么就讀取X的最新commit的版本，也就是X=2

如果事務B是Repeatable Read。那么讀取的就是當前事務(txnId=101)之前X的最新版本，也就是X被txnId=100提交的版本，即X=1。

注意，這里B不論是Read Committed，還是Repeatable Read，都不會被鎖，都能立刻拿到結果。這也就是MVCC存在的意義。

在基于MVCC的數據庫實現中，根本就不需要出現Read Uncommitted這種情況。Read Uncommitted是早期數據庫，讀寫都基于鎖進行實現的產物。在實際業務中Read Uncommitted毫無意義(如果真有意義，你咋不去用NoSQL數據庫？)因此：對于Postgres，Read Committed和Read Uncommitted是一樣的。

對于Oracle，壓根就沒有Read Uncommitted這個級別。

所以從實際的角度出發，我想所有人都忘記有“Read Uncommitted”這件事。

MVCC并不是萬靈藥。大量的業務問題的關鍵點在于，你在提交一個事務那一剎那，你提交事務的所有修改依賴的讀取是否都還有效。對于這種場景，無論是Read Committed還是Repeatable Read都沒有什么卵用。比如扣庫存就是這樣典型的業務場景。

在這種場景下在MySQL InnoDB，使用者會使用select ... for update手工加鎖。或者干脆用Serializable隔離級別。

在Postgres，Postgres的Repeatable Read在提交時會提供一個“提交的修改的依賴是否被修改“的檢測(好繞口，但就是這個意思)。如果依賴已經被改掉了，當前事務提交一定會失敗。

希望上面的簡單回答可以讓你重新對數據庫、鎖和隔離級別有所認識。如果沒看懂也不奇怪，問題本身的確非常復雜，所以我專門寫了一篇很長的文字來解釋這個問題，希望可以幫到你。

數據庫事務、隔離級別和鎖?www.jianshu.com

總結

以上是生活随笔為你收集整理的mysql隔离级别和mvcc_数据库MVCC和隔离级别的关系是什么？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。