2. 程式人生 > 其它 >一文明白資料庫事務隔離級別

一文明白資料庫事務隔離級別

阿新 • • 發佈：2021-12-21

網路上關於這方面的博文有些偏理論，有些通篇程式碼，都不能深入淺出。本文用圖文並茂的方式，配上行雲流水般的程式碼，非要擺清楚這個問題。相關程式碼已提交至碼雲（點選這裡下載）。

事務是現代關係型資料庫的核心之一。在多個事務併發操作資料庫（多執行緒、網路併發等）的時候，如果沒有有效的避免機制，就會出現以下幾種問題：

第一類丟失更新（Lost Update）

在完全未隔離事務的情況下，兩個事務更新同一條資料資源，某一事務完成，另一事務異常終止，回滾造成第一個完成的更新也同時丟失 。這個問題現代關係型資料庫已經不會發生，就不在這裡佔用篇幅，有興趣的可以自行百度。

髒讀（Dirty Read）

A事務執行過程中，B事務讀取了A事務的修改。但是由於某些原因，A事務可能沒有完成提交，發生RollBack了操作，則B事務所讀取的資料就會是不正確的。這個未提交資料就是髒讀（Dirty Read）。髒讀產生的流程如下：

可以用EF Core模擬此過程：

    class TestReadUncommitted :TestBase
    {
        private AutoResetEvent _autoResetEvent;

        [Test]
        public void ReadUncommitted()
        {
            using (var context = _autofacServiceProvider.GetService<OpenAuthDBContext>())
            {
                var user = context.Users.SingleOrDefault(u => u.Account == "admin");
                Console.WriteLine($"初始使用者狀態:【{user.Status}】");
            }

            _autoResetEvent = new AutoResetEvent(false);
            ThreadPool.QueueUserWorkItem(data =>{
                Write();  //啟動執行緒寫
            });
            ThreadPool.QueueUserWorkItem(data =>{
                Read();  //啟動執行緒讀
            });

            Thread.Sleep(5000);

            using (var context = _autofacServiceProvider.GetService<OpenAuthDBContext>())
            {
                var user = context.Users.SingleOrDefault(u => u.Account == "admin");
                Console.WriteLine($"終端使用者狀態:【{user.Status}】");
            }
        }

        private void Read()
        {
            _autoResetEvent.WaitOne();

            var options = new TransactionOptions { IsolationLevel = IsolationLevel.ReadUncommitted };
            using (var scope = new TransactionScope(TransactionScopeOption.Required, options))
            {
                using (var context = _autofacServiceProvider.GetService<OpenAuthDBContext>())
                {
                    var user = context.Users.SingleOrDefault(u => u.Account == "admin");
                    Console.WriteLine($"事務B：髒讀到的使用者狀態:【{user.Status}】--{DateTime.Now.ToString("HH:mm:ss fff")}");
                    //如果這時執行下面的判斷
                    if (user.Status == 1)
                    {
                        Console.WriteLine("事務B：非正常資料，會產生意想不到的BUG");
                    }
                }
            }
        }
        private void Write()
        {
            using (var scope = new TransactionScope(TransactionScopeOption.Required,
                new TransactionOptions {IsolationLevel = IsolationLevel.ReadCommitted}))
            {
                Console.WriteLine($"事務A：修改--{DateTime.Now.ToString("HH:mm:ss fff")}");
                using (var context = _autofacServiceProvider.GetService<OpenAuthDBContext>())
                {
                    var user = context.Users.SingleOrDefault(u => u.Account == "admin");
                    user.Status = 1-user.Status;  //模擬修改
                    context.SaveChanges();
                }

                _autoResetEvent.Set();  //模擬多執行緒切換，這時切換到Read執行緒，復現髒讀

                Thread.Sleep(2000);  //模擬長事務
                Console.WriteLine($"事務A：改完，但沒提交--{DateTime.Now.ToString("HH:mm:ss fff")}");
            }
        }
    }

對應的執行結果：

不可重複讀（Nonrepeatable Read）

B事務讀取了兩次資料，在這兩次的讀取過程中A事務修改了資料，B事務的這兩次讀取出來的資料不一樣。B事務這種讀取的結果，即為不可重複讀（Nonrepeatable Read）。不可重複讀的產生的流程如下：

模擬程式碼如下：

public class TestReadCommitted : TestBase
    {
        private AutoResetEvent _toWriteEvent = new AutoResetEvent(false);
        private AutoResetEvent _toReadEvent = new AutoResetEvent(false);

        [Test]
        public void ReadCommitted()
        {
            ThreadPool.QueueUserWorkItem(data => {
                Read();  //啟動執行緒讀
            });
            ThreadPool.QueueUserWorkItem(data => {
                Write();  //啟動執行緒寫
            });

            Thread.Sleep(5000);

            using (var context = _autofacServiceProvider.GetService<OpenAuthDBContext>())
            {
                var user = context.Users.SingleOrDefault(u => u.Account == "admin");
                Console.WriteLine($"終端使用者狀態:【{user.Status}】--{DateTime.Now.ToString("HH:mm:ss fff")}");
            }

        }

        private void Read()
        {
            using (var transactionScope = new TransactionScope(TransactionScopeOption.Required,
                new TransactionOptions { IsolationLevel = IsolationLevel.ReadCommitted }))
            {
                using (var context = _autofacServiceProvider.GetService<OpenAuthDBContext>())
                {
                    var user = context.Users.SingleOrDefault(u => u.Account == "admin");
                    Console.WriteLine($"事務B：第一次讀取:【{user.Status}】--{DateTime.Now.ToString("HH:mm:ss fff")}");
                }

                _toWriteEvent.Set();  //模擬多執行緒切換，這時切換到寫執行緒，復現不可重複讀
                _toReadEvent.WaitOne();

                using (var context = _autofacServiceProvider.GetService<OpenAuthDBContext>())
                {
                    var user = context.Users.SingleOrDefault(u => u.Account == "admin");
                    Console.WriteLine($"事務B：第二次讀取:【{user.Status}】--{DateTime.Now.ToString("HH:mm:ss fff")}");
                }
            }

        }

        private void Write()
        {
            _toWriteEvent.WaitOne();

            using (var scope = new TransactionScope(TransactionScopeOption.Required,
                new TransactionOptions { IsolationLevel = IsolationLevel.ReadCommitted }))
            {
                User user = null;
                using (var context = _autofacServiceProvider.GetService<OpenAuthDBContext>())
                {
                    user = context.Users.SingleOrDefault(u => u.Account == "admin");
                    Console.WriteLine($"事務A：讀取為【{user?.Status}】--{DateTime.Now.ToString("HH:mm:ss fff")}");
                    user.Status = 1 - user.Status;
                    context.SaveChanges();
                }
                scope.Complete();
                Console.WriteLine($"事務A：已被更改為【{user.Status}】--{DateTime.Now.ToString("HH:mm:ss fff")}");
                _toReadEvent.Set();
            }
        }
    }

對應的執行結果：

不可重複讀有一種特殊情況，兩個事務更新同一條資料資源，後完成的事務會造成先完成的事務更新丟失。這種情況就是大名鼎鼎的第二類丟失更新。主流的資料庫已經預設遮蔽了第一類丟失更新問題（即：後做的事務撤銷，發生回滾造成已完成事務的更新丟失），但我們程式設計的時候仍需要特別注意第二類丟失更新。它產生的流程如下：

模擬程式碼如下：

public class TestReadCommitted2 : TestBase
    {
        private AutoResetEvent _toWriteEvent = new AutoResetEvent(false);
        private AutoResetEvent _toReadEvent = new AutoResetEvent(false);

        [Test]
        public void ReadCommitted()
        {
            ThreadPool.QueueUserWorkItem(data => {
                Read();  //啟動執行緒讀
            });
            ThreadPool.QueueUserWorkItem(data => {
                Write();  //啟動執行緒寫
            });

            Thread.Sleep(5000);

            using (var context = _autofacServiceProvider.GetService<OpenAuthDBContext>())
            {
                var user = context.Users.SingleOrDefault(u => u.Account == "admin");
                Console.WriteLine($"終端使用者狀態:【{user.Status}】--{DateTime.Now.ToString("HH:mm:ss fff")}");
            }
        }

        private void Read()
        {
            using (var transactionScope = new TransactionScope(TransactionScopeOption.Required,
                new TransactionOptions { IsolationLevel = IsolationLevel.ReadCommitted }))
            {
                User user = null;
                using (var context = _autofacServiceProvider.GetService<OpenAuthDBContext>())
                {
                    user = context.Users.SingleOrDefault(u => u.Account == "admin");
                    Console.WriteLine($"事務B：第一次讀取:【{user?.Status}】--{DateTime.Now.ToString("HH:mm:ss fff")}");
                }

                _toWriteEvent.Set();  //模擬多執行緒切換，這時切換到寫執行緒，復現不可重複讀
                _toReadEvent.WaitOne();

                using (var context = _autofacServiceProvider.GetService<OpenAuthDBContext>())
                {
                    user = context.Users.SingleOrDefault(u => u.Account == "admin");
                    Console.WriteLine($"事務B：第二次讀取:【{user?.Status}】--{DateTime.Now.ToString("HH:mm:ss fff")}");
                    user.Status = 1 - user.Status;
                    context.SaveChanges();
                }
                transactionScope.Complete();
                Console.WriteLine($"事務B：已被更改為【{user?.Status}】--{DateTime.Now.ToString("HH:mm:ss fff")}");
            }

        }

        private void Write()
        {
            _toWriteEvent.WaitOne();

            using (var scope = new TransactionScope(TransactionScopeOption.Required,
                new TransactionOptions { IsolationLevel = IsolationLevel.ReadCommitted }))
            {
                User user = null;
                using (var context = _autofacServiceProvider.GetService<OpenAuthDBContext>())
                {
                    user = context.Users.SingleOrDefault(u => u.Account == "admin");
                    Console.WriteLine($"事務A：讀取為【{user?.Status}】--{DateTime.Now.ToString("HH:mm:ss fff")}");
                    user.Status = 1 - user.Status;
                    context.SaveChanges();
                }
                scope.Complete();
                Console.WriteLine($"事務A：已被更改為【{user.Status}】--{DateTime.Now.ToString("HH:mm:ss fff")}");
                _toReadEvent.Set();
            }
        }
    }

對應的執行結果如下圖：

可以明顯看出事務A的更新被事務B所覆蓋，更新丟失。

幻讀（Phantom Read）

B事務讀取了兩次資料，在這兩次的讀取過程中A事務添加了資料，B事務的這兩次讀取出來的集合不一樣。幻讀產生的流程如下：

這個流程看起來和不可重複讀差不多，但幻讀強調的集合的增減，而不是單獨一條資料的修改。

模擬程式碼如下：

public class TestRepeat : TestBase
    {
        private AutoResetEvent _toWriteEvent = new AutoResetEvent(false);
        private AutoResetEvent _toReadEvent = new AutoResetEvent(false);

        [Test]
        public void Repeat()
        {
            ThreadPool.QueueUserWorkItem(data => {
                Read();  //啟動執行緒讀
            });
            ThreadPool.QueueUserWorkItem(data => {
                Write();  //啟動執行緒寫
            });

            Thread.Sleep(6000);

        }

        private void Read()
        {
            using (var transactionScope = new TransactionScope(TransactionScopeOption.Required,
                new TransactionOptions { IsolationLevel = IsolationLevel.RepeatableRead }))
            {
                using (var context = _autofacServiceProvider.GetService<OpenAuthDBContext>())
                {
                    Console.WriteLine($"事務B：第一次讀取:【{context.Users.Count()}】--{DateTime.Now.ToString("HH:mm:ss fff")}");
                }

                _toWriteEvent.Set();  //模擬多執行緒切換，這時切換到寫執行緒，復現幻讀
                _toReadEvent.WaitOne();

                using (var context = _autofacServiceProvider.GetService<OpenAuthDBContext>())
                {
                    Console.WriteLine($"事務B：第二次讀取:【{context.Users.Count()}】--{DateTime.Now.ToString("HH:mm:ss fff")}");
                }
            }

        }

        private void Write()
        {
            _toWriteEvent.WaitOne();

            using (var scope = new TransactionScope(TransactionScopeOption.Required,
                     new TransactionOptions { IsolationLevel = IsolationLevel.ReadCommitted }))
            {
                Console.WriteLine($"事務A：新增一條--{DateTime.Now.ToString("HH:mm:ss fff")}");
                using (var context = _autofacServiceProvider.GetService<OpenAuthDBContext>())
                {
                    var id = GenerateId.ShortStr();
                    context.Users.Add(new User { Id = id, Account = id, Status = 0, Name = id, CreateTime = DateTime.Now});
                    context.SaveChanges();
                }
                scope.Complete();
                Console.WriteLine($"事務A：完成新增--{DateTime.Now.ToString("HH:mm:ss fff")}");
                _toReadEvent.Set();
            }
        }
    }

執行結果：

資料庫隔離級別

為了解決上面提及的併發問題，主流關係型資料庫都會提供四種事務隔離級別。

讀未提交（Read Uncommitted）

在該隔離級別，所有事務都可以看到其他未提交事務的執行結果。本隔離級別是最低的隔離級別，雖然擁有超高的併發處理能力及很低的系統開銷，但很少用於實際應用。因為採用這種隔離級別只能防止第一類更新丟失問題，不能解決髒讀，不可重複讀及幻讀問題。

讀已提交（Read Committed）

這是大多數資料庫系統的預設隔離級別（但不是MySQL預設的）。它滿足了隔離的簡單定義：一個事務只能看見已經提交事務所做的改變。這種隔離級別可以防止髒讀問題，但會出現不可重複讀及幻讀問題。

可重複讀（Repeatable Read）

這是MySQL的預設事務隔離級別，它確保同一事務的多個例項在併發讀取資料時，會看到同樣的資料行。這種隔離級別可以防止除幻讀外的其他問題。

可序列化（Serializable）

這是最高的隔離級別，它通過強制事務排序，使之不可能相互衝突，從而解決幻讀、第二類更新丟失問題。在這個級別，可以解決上面提到的所有併發問題，但可能導致大量的超時現象和鎖競爭，通常資料庫不會用這個隔離級別，我們需要其他的機制來解決這些問題:樂觀鎖和悲觀鎖。

這四種隔離級別會產生的問題如下（網上到處都有，懶得畫了）：

如何使用資料庫的隔離級別

很多文章部落格在介紹完這些隔離級別以後，就沒有以後了。讀的人一般會覺得，嗯，是這麼回事，我知道了！

學習一個知識點，是需要實踐的。比如下面這個常見而又異常嚴重的情況：

圖中是典型的第二類丟失更新問題，後果異常嚴重。我們這裡就以讀已提交（Read Committed）及以下隔離級別中會出現不可重複讀現象為例。從上面的表格可以看出，當事務隔離級別為可重複讀（Repeatable Read）時可以避免。把TestReadCommitted中的Read執行緒事務級別調整一下：

////////////////////////////////////////////////////////////////////////////////////////////////////
// file:	Test\TestReadCommitted.cs
//
// summary:	讀已提交會出現“不可重複讀”現象
//              把讀執行緒（事務B）的隔離級別調整到RepeatableRead，即可杜絕
////////////////////////////////////////////////////////////////////////////////////////////////////

using System;
using System.Linq;
using System.Threading;
using System.Transactions;
using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.DependencyInjection;
using NUnit.Framework;
using TestTransaction.Domain;

namespace TestTransaction.Test
{
    public class TestReadCommitted : TestBase
    {
        private AutoResetEvent _toWriteEvent = new AutoResetEvent(false);
        private AutoResetEvent _toReadEvent = new AutoResetEvent(false);

        [Test]
        public void ReadCommitted()
        {
            ThreadPool.QueueUserWorkItem(data => {
                Read();  //啟動執行緒讀
            });
            ThreadPool.QueueUserWorkItem(data => {
                Write();  //啟動執行緒寫
            });

            Thread.Sleep(60000);

            using (var context = _autofacServiceProvider.GetService<OpenAuthDBContext>())
            {
                var user = context.Users.SingleOrDefault(u => u.Account == "admin");
                Console.WriteLine($"終端使用者狀態:【{user.Status}】--{DateTime.Now.ToString("HH:mm:ss fff")}");
            }

        }

        private void Read()
        {
            //讀執行緒（事務B）的隔離級別調整到RepeatableRead
            using (var transactionScope = new TransactionScope(TransactionScopeOption.Required,
                new TransactionOptions { IsolationLevel = IsolationLevel.RepeatableRead, Timeout = TimeSpan.FromSeconds(40) }))
            {
                using (var context = _autofacServiceProvider.GetService<OpenAuthDBContext>())
                {
                    var user = context.Users.SingleOrDefault(u => u.Account == "admin");
                    Console.WriteLine($"事務B：第一次讀取:【{user.Status}】--{DateTime.Now.ToString("HH:mm:ss fff")}");
                }

                _toWriteEvent.Set();  //模擬多執行緒切換，這時切換到寫執行緒，復現不可重複讀
                _toReadEvent.WaitOne();

                using (var context = _autofacServiceProvider.GetService<OpenAuthDBContext>())
                {
                    var user = context.Users.SingleOrDefault(u => u.Account == "admin");
                    Console.WriteLine($"事務B：第二次讀取:【{user.Status}】--{DateTime.Now.ToString("HH:mm:ss fff")}");
                }
            }

        }

        private void Write()
        {
            _toWriteEvent.WaitOne();

            using (var scope = new TransactionScope(TransactionScopeOption.Required,
                new TransactionOptions { IsolationLevel = IsolationLevel.ReadCommitted, Timeout = TimeSpan.FromSeconds(5) }))
            {
                User user = null;
                using (var context = _autofacServiceProvider.GetService<OpenAuthDBContext>())
                {
                    user = context.Users.SingleOrDefault(u => u.Account == "admin");
                    Console.WriteLine($"事務A：讀取為【{user?.Status}】--{DateTime.Now.ToString("HH:mm:ss fff")}");
                    user.Status = 1 - user.Status;
                    try
                    {
                        context.SaveChanges();
                        scope.Complete();

                        Console.WriteLine($"事務A：已被更改為【{user.Status}】--{DateTime.Now.ToString("HH:mm:ss fff")}");
                    }
                    catch (DbUpdateException e)
                    {
                        Console.WriteLine($"事務A：異常，為了保證可重複讀，你的修改提交失敗，請稍後重試--{DateTime.Now.ToString("HH:mm:ss fff")}");
                    }
                }
                _toReadEvent.Set();
            }
        }
    }
}

這時執行效果如下：

實際專案中，通過提示客戶端重做的方式，完美解決了不可重複讀的問題。其他併發問題，也可以通過類似的方式解決。

zz：https://www.cnblogs.com/yubaolee/p/10398633.html

相關推薦

一文明白資料庫事務隔離級別

網路上關於這方面的博文有些偏理論，有些通篇程式碼，都不能深入淺出。本文用圖文並茂的方式，配上行雲流水般的程式碼，非要擺清楚這個問題。相關程式碼已提交至碼雲（點選這裡下載）。

資料庫 事務隔離級別和傳播行為以及@Transactional使用規範

一、事務隔離級別： 資料庫事務的隔離級別有4個，由低到高依次為Read uncommitted、Read committed、Repeatable read、Serializable，這四個級別可以逐個解決髒讀、不可重複讀、幻讀這幾類問題。

資料庫事務的特性以及MySQL資料庫的隔離級別

前言 瞭解資料庫事務的特性，能夠讓我們更好的理解程式設計的時候對資料庫事務的控制。本篇文章主要講解了資料庫事務的特性以及MySQL資料庫在不同的事務隔離級別下遇到的不同情況。

分散式事務一--Mysql本地事務和事務隔離級別

分散式事務（一）Mysql本地事務和事務隔離級別 資料庫事務 資料庫事務由一組sql語句組成。

Spring支援的常用資料庫事務傳播屬性和事務隔離級別

1、事務的傳播行為 1.1、傳播行為簡介 1.2、事務的測試程式碼（這裡只測試了兩種）

事務的四大特性ACID和資料庫的隔離級別

技術標籤：mysqlsql 事務的四大特性ACID 資料庫四大屬性原子性(Atomicity)，一致性(Consistency)，隔離性(Isolation)，一致性(Durability)

Spring支援的常用資料庫事務傳播屬性和事務隔離級別？

事務傳播屬性 事務的傳播行為：一個方法執行在了一個開啟了事務的方法中時，當前方法是使用原來的事務還是開啟一個新的事務

一文解析Spring事務管理詳解；通俗易懂，輕鬆掌握！

事務概念回顧 什麼是事務？ 事務是邏輯上的一組操作，要麼都執行，要麼都不執行.

事務隔離級別和Spirng事務傳播級別

事務的四個特性（ACID） 原子性 一個事務（transaction）中的所有操作，或者全部完成，或者全部不完成，不會結束在中間某個環節。事務在執行過程中發生錯誤，會被回滾（Rollback）到事務開始前的狀態，就像這個事務從

淺談Spring的事務隔離級別與傳播性

這篇文章以一個問題開始，如果你知道答案的話就可以跳過不看啦@(o･ｪ･)@

鋼筋之Mysql隱式提交和事務隔離級別的關係

前言 筆者自詡對Mysql的知識積累已經很不錯了，現在看來不過是對CRUD操作比較熟悉罷了。

Mysql事務隔離級別之讀提交詳解

檢視mysql 事務隔離級別 mysql> show variables like \'%isolation%\'; +---------------+----------------+

innodb如何巧妙的實現事務隔離級別詳解

前言 之前的文章mysql鎖機制詳解中我們詳細講解了innodb的鎖機制，鎖機制是用來保證在併發情況下資料的準確性，而要保證資料準確通常需要事務的支援，而mysql儲存引擎innodb是通過鎖機制來巧妙地實現事務的隔離特性中

MySQL檢視和修改事務隔離級別的例項講解

檢視事務隔離級別 在 MySQL 中，可以通過show variables like \'%tx_isolation%\'或select @@tx_isolation;語句來檢視當前事務隔離級別。

Mysql事務隔離級別原理例項解析

引言 大家在面試中一定碰到過 說說事務的隔離級別吧？ 老實說，事務隔離級別這個問題，無論是校招還是社招，面試官都愛問！然而目前網上很多文章，說句實在話啊，我看了後我都懷疑作者弄懂沒!因為他們對可重複讀(Rep

Mariadb之事務隔離級別

　　上一篇我們聊到了mariadb的鎖，以及怎麼手動加鎖和解鎖等等，回顧請參考https://www.cnblogs.com/qiuhom-1874/p/13196905.html；今天我們來聊一聊mariadb的事務隔離級別；在前邊的隨筆中，我們提到到了mysql的儲

MySQL中事務隔離級別

最近在學習資料庫的事務隔離級別。在這裡整理一下。由於本人水平和寫作能力有限，如文中有錯誤或者表達不清楚的地方，請多包涵。有任何意見或建議，歡迎留言。

【MySQL】搞懂ACID原則和事務隔離級別

宜未雨而綢繆，毋臨渴而掘井 什麼是事務 資料庫事務(Database Transaction) ，是指作為單個邏輯工作單元執行的一系列操作，要麼全部執行，要麼全部不執行。

【mysql】- 事務隔離級別和MVCC篇

概念 術語 髒寫（ Dirty Write ）: 如果一個事務修改了另一個未提交事務修改過的資料，那就意味著發了髒寫

mysql的4種事務隔離級別

mysql的4種事務隔離級別 事務的基本要素ACID 原子性 : 事務是一個不可分割的整體,要麼全部做完,要麼全部不做. Atomicity