MVCC-資料庫
參考地址：看一遍就理解：MVCC原理詳解 - 掘金 (juejin.cn)
1. 相關資料庫知識點回顧
1.1 什麼是資料庫事務，為什麼要有事務
事務，由一個有限的資料庫操作序列構成，這些操作要麼全部執行,要麼全部不執行，是一個不可分割的工作單位。
假如A轉賬給B 100 元，先從A的賬戶里扣除 100 元，再在 B 的賬戶上加上 100 元。如果扣完A的100元后，還沒來得及給B加上，銀行系統異常了，最後導致A的餘額減少了，B的餘額卻沒有增加。所以就需要事務，將A的錢回滾回去，就是這麼簡單。
為什麼要有事務呢？ 就是為了保證資料的最終一致性。
1.2 事務包括哪幾個特性？
事務四個典型特性，即ACID，原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、永續性（Durability）。
- 原子性： 事務作為一個整體被執行，包含在其中的對資料庫的操作要麼全部都執行，要麼都不執行。
- 一致性： 指在事務開始之前和事務結束以後，資料不會被破壞，假如A賬戶給B賬戶轉10塊錢，不管成功與否，A和B的總金額是不變的。
- 隔離性： 多個事務並行存取時，事務之間是相互隔離的，一個事務不應該被其他事務干擾，多個並行事務之間要相互隔離。。
- 永續性： 表示事務完成提交後，該事務對資料庫所作的操作更改，將持久地儲存在資料庫之中。
1.3 事務並行存在的問題
事務並行會引起髒讀、不可重複讀、幻讀問題。
1.3.1 髒讀
如果一個事務讀取到了另一個未提交事務修改過的資料，我們就稱發生了髒讀現象。
假設現在有兩個事務A、B：
- 假設現在A的餘額是100，事務A正在準備查詢Jay的餘額
- 事務B先扣減Jay的餘額，扣了10，但是還沒提交
- 最後A讀到的餘額是90，即扣減後的餘額
因為事務A讀取到事務B未提交的資料,這就是髒讀。
1.3.2 不可重複讀
同一個事務內，前後多次讀取，讀取到的資料內容不一致
假設現在有兩個事務A和B：
- 事務A先查詢Jay的餘額，查到結果是100
- 這時候事務B 對Jay的賬戶餘額進行扣減，扣去10後，提交事務
- 事務A再去查詢Jay的賬戶餘額發現變成了90
事務A被事務B干擾到了！在事務A範圍內，兩個相同的查詢，讀取同一條記錄，卻返回了不同的資料，這就是不可重複讀。
1.3.3 幻讀
如果一個事務先根據某些搜尋條件查詢出一些記錄，在該事務未提交時，另一個事務寫入了一些符合那些搜尋條件的記錄（如insert、delete、update），就意味著發生了幻讀。
假設現在有兩個事務A、B：
- 事務A先查詢id大於2的賬戶記錄，得到記錄id=2和id=3的兩條記錄
- 這時候，事務B開啟，插入一條id=4的記錄，並且提交了
- 事務A再去執行相同的查詢，卻得到了id=2,3,4的3條記錄了。
事務A查詢一個範圍的結果集，另一個並行事務B往這個範圍中插入新的資料，並提交事務，然後事務A再次查詢相同的範圍，兩次讀取到的結果集卻不一樣了，這就是幻讀。
1.4 四大隔離級別
為了解決並行事務存在的髒讀、不可重複讀、幻讀等問題，資料庫大叔設計了四種隔離級別。分別是讀未提交，讀已提交，可重複讀，序列化（Serializable）。
1.4.1 讀未提交
讀未提交隔離級別，只限制了兩個資料不能同時修改，但是修改資料的時候，即使事務未提交，都是可以被別的事務讀取到的，這級別的事務隔離有髒讀、重複讀、幻讀的問題；
1.4.2 讀已提交
讀已提交隔離級別，當前事務只能讀取到其他事務提交的資料，所以這種事務的隔離級別解決了髒讀問題，但還是會存在重複讀、幻讀問題；
1.4 3 可重複讀
可重複讀隔離級別，限制了讀取資料的時候，不可以進行修改，所以解決了重複讀的問題，但是讀取範圍資料的時候，是可以插入資料，所以還會存在幻讀問題；
1.4.4 序列化
事務最高的隔離級別，在該級別下，所有事務都是進行序列化順序執行的。可以避免髒讀、不可重複讀與幻讀所有並行問題。但是這種事務隔離級別下，事務執行很耗效能。
1.4.5 四大隔離級別，都會存在哪些並行問題呢
| 隔離級別 | 髒讀 | 不可重複讀 | 幻讀 |
|---|---|---|---|
| 讀未提交 | √ | √ | √ |
| 讀已提交 | × | √ | √ |
| 可重複讀 | × | × | √ |
| 序列化 | × | × | × |
1.5 資料庫是如何保證事務的隔離性的呢？
資料庫是通過加鎖，來實現事務的隔離性的。這就好像，如果你想一個人靜靜，不被別人打擾，你就可以在房門上加上一把鎖。
加鎖確實好使，可以保證隔離性。比如序列化隔離級別就是加鎖實現的。但是頻繁的加鎖，導致讀資料時，沒辦法修改，修改資料時，沒辦法讀取，大大降低了資料庫效能。
那麼，如何解決加鎖後的效能問題的？
答案就是,MVCC多版本並行控制！它實現讀取資料不用加鎖，可以讓讀取資料同時修改。修改資料時同時可讀取。
2. 什麼是 MVCC？
MVCC，即Multi-Version Concurrency Control （多版本並行控制）。它是一種並行控制的方法，一般在資料庫管理系統中，實現對資料庫的並行存取，在程式語言中實現事務記憶體。
通俗的講，資料庫中同時存在多個版本的資料，並不是整個資料庫的多個版本，而是某一條記錄的多個版本同時存在，在某個事務對其進行操作的時候，需要檢視這一條記錄的隱藏列事務版本id，比對事務id並根據事物隔離級別去判斷讀取哪個版本的資料。
資料庫隔離級別讀已提交、可重複讀 都是基於MVCC實現的，相對於加鎖簡單粗暴的方式，它用更好的方式去處理讀寫衝突，能有效提高資料庫並行效能。
3. MVCC實現的關鍵知識點
3.1 事務版本號
事務每次開啟前，都會從資料庫獲得一個自增長的事務ID，可以從事務ID判斷事務的執行先後順序。這就是事務版本號。
3.2 隱式欄位
對於InnoDB儲存引擎，每一行記錄都有兩個隱藏列trx_id、roll_pointer，如果表中沒有主鍵和非NULL唯一鍵時，則還會有第三個隱藏的主鍵列row_id。
| 列名 | 是否必須 | 描述 |
|---|---|---|
| row_id | 否 | 單調遞增的行ID，不是必需的，佔用6個位元組。 |
| trx_id | 是 | 記錄操作該資料事務的事務ID |
| roll_pointer | 是 | 這個隱藏列就相當於一個指標，指向回滾段的undo紀錄檔 |
3.3 undo log
undo log，回滾紀錄檔，用於記錄資料被修改前的資訊。在表記錄修改之前，會先把資料拷貝到undo log裡，如果事務回滾，即可以通過undo log來還原資料。
可以這樣認為，當delete一條記錄時，undo log 中會記錄一條對應的insert記錄，當update一條記錄時，它記錄一條對應相反的update記錄。
undo log有什麼用途呢？
- 事務回滾時，保證原子性和一致性。
- 用於MVCC快照讀。
3.4 版本鏈
多個事務並行操作某一行資料時，不同事務對該行資料的修改會產生多個版本，然後通過回滾指標（roll_pointer），連成一個連結串列，這個連結串列就稱為版本鏈。如下：
其實，通過版本鏈，我們就可以看出事務版本號、表格隱藏的列和undo log它們之間的關係。我們再來小分析一下。
- 假設現在有一張core_user表，表裡面有一條資料,id為1，名字為孫權：
- 現在開啟一個事務A： 對core_user表執行
update core_user set name ="曹操" where id=1,會進行如下流程操作
- 首先獲得一個事務ID=100
- 把core_user表修改前的資料,拷貝到undo log
- 修改core_user表中，id=1的資料，名字改為曹操
- 把修改後的資料事務Id=101改成當前事務版本號，並把roll_pointer指向undo log資料地址。
3.5 快照讀和當前讀
快照讀： 讀取的是記錄資料的可見版本（有舊的版本）。不加鎖,普通的select語句都是快照讀,如：
select * from core_user where id > 2;
當前讀：讀取的是記錄資料的最新版本，顯式加鎖的都是當前讀
select * from core_user where id > 2 for update;
select * from account where id>2 lock in share mode;
3.6 Read View
- Read View是什麼呢？ 它就是事務執行SQL語句時，產生的讀檢視。實際上在innodb中，每個SQL語句執行前都會得到一個Read View。
- Read View有什麼用呢？ 它主要是用來做可見性判斷的，即判斷當前事務可見哪個版本的資料~
Read View是如何保證可見性判斷的呢？我們先看看Read view 的幾個重要屬性
- m_ids:當前系統中那些活躍(未提交)的讀寫事務ID, 它資料結構為一個List。
- min_limit_id:表示在生成ReadView時，當前系統中活躍的讀寫事務中最小的事務id，即m_ids中的最小值。
- max_limit_id:表示生成ReadView時，系統中應該分配給下一個事務的id值。
- creator_trx_id: 建立當前read view的事務ID
Read view 匹配條件規則如下：
- 如果資料事務ID
trx_id < min_limit_id，表明生成該版本的事務在生成Read View前，已經提交(因為事務ID是遞增的)，所以該版本可以被當前事務存取。 - 如果
trx_id>= max_limit_id，表明生成該版本的事務在生成ReadView後才生成，所以該版本不可以被當前事務存取。 - 如果
min_limit_id =<trx_id< max_limit_id,需腰分3種情況討論
- （1）.如果
m_ids包含trx_id,則代表Read View生成時刻，這個事務還未提交，但是如果資料的trx_id等於creator_trx_id的話，表明資料是自己生成的，因此是可見的。- （2）如果
m_ids包含trx_id，並且trx_id不等於creator_trx_id，則Read View生成時，事務未提交，並且不是自己生產的，所以當前事務也是看不見的；- （3）.如果
m_ids不包含trx_id，則說明你這個事務在Read View生成之前就已經提交了，修改的結果，當前事務是能看見的。
4. MVCC實現原理分析
4.1 查詢一條記錄，基於MVCC，是怎樣的流程
- 獲取事務自己的版本號，即事務ID
- 獲取Read View
- 查詢得到的資料，然後Read View中的事務版本號進行比較。
- 如果不符合Read View的可見性規則， 即就需要Undo log中歷史快照;
- 最後返回符合規則的資料
InnoDB 實現MVCC，是通過 Read View+ Undo Log 實現的，Undo Log 儲存了歷史快照，Read View可見性規則幫助判斷當前版本的資料是否可見。
4.2 讀已提交（RC）隔離級別，存在不可重複讀問題的分析歷程
- 建立core_user表，插入一條初始化資料,如下：
- 隔離級別設定為讀已提交（RC），事務A和事務B同時對core_user表進行查詢和修改操作。
事務A: select * fom core_user where id=1
事務B: update core_user set name =」曹操」
執行流程如下：
最後事務A查詢到的結果是，name=曹操的記錄，我們基於MVCC，來分析一下執行流程：
(1). A開啟事務，首先得到一個事務ID為100
(2).B開啟事務，得到事務ID為101
(3).事務A生成一個Read View，read view對應的值如下
| 變數 | 值 |
|---|---|
| m_ids | 100，101 |
| max_limit_id | 102 |
| min_limit_id | 100 |
| creator_trx_id | 100 |
然後回到版本鏈：開始從版本鏈中挑選可見的記錄：
由圖可以看出，最新版本的列name的內容是孫權，該版本的trx_id值為100。開始執行read view可見性規則校驗：
min_limit_id(100)=<trx_id（100）<102;
creator_trx_id = trx_id =100;
由此可得，trx_id=100的這個記錄，當前事務是可見的。所以查到是name為孫權的記錄。
（4). 事務B進行修改操作，把名字改為曹操。把原資料拷貝到undo log,然後對資料進行修改，標記事務ID和上一個資料版本在undo log的地址。
(5) 提交事務
(6) 事務A再次執行查詢操作，新生成一個Read View，Read View對應的值如下
| 變數 | 值 |
|---|---|
| m_ids | 100 |
| max_limit_id | 102 |
| min_limit_id | 100 |
| creator_trx_id | 100 |
然後再次回到版本鏈：從版本鏈中挑選可見的記錄：
從圖可得，最新版本的列name的內容是曹操，該版本的trx_id值為101。開始執行Read View可見性規則校驗：
min_limit_id(100)=<trx_id（101）<max_limit_id（102);
但是,trx_id=101，不屬於m_ids集合
因此，trx_id=101這個記錄，對於當前事務是可見的。所以SQL查詢到的是name為曹操的記錄。
綜上所述，在讀已提交（RC）隔離級別下，同一個事務裡，兩個相同的查詢，讀取同一條記錄（id=1），卻返回了不同的資料（第一次查出來是孫權，第二次查出來是曹操那條記錄），因此RC隔離級別，存在不可重複讀並行問題。
4.3 可重複讀（RR）隔離級別，解決不可重複讀問題的分析
在RR隔離級別下，是如何解決不可重複讀問題的呢？我們一起再來看下，
還是4.2小節那個流程，還是這個事務A和事務B，如下：
4.3.1 不同隔離級別下，Read view的工作方式不同
實際上，各種事務隔離級別下的Read view工作方式，是不一樣的，RR可以解決不可重複讀問題，就是跟Read view工作方式有關。
- 在讀已提交（RC）隔離級別下，同一個事務裡面，每一次查詢都會產生一個新的Read View副本，這樣就可能造成同一個事務裡前後讀取資料可能不一致的問題（不可重複讀並行問題）。
| begin | |
|---|---|
| select * from core_user where id =1 | 生成一個Read View |
| / | / |
| / | / |
| select * from core_user where id =1 | 生成一個Read View |
- 在可重複讀（RR）隔離級別下，一個事務裡只會獲取一次read view，都是副本共用的，從而保證每次查詢的資料都是一樣的。
| begin | |
|---|---|
| select * from core_user where id =1 | 生成一個Read View |
| / | |
| / | |
| select * from core_user where id =1 | 共用一個Read View副本 |
4.3.2 範例分析
我們穿越下，回到剛4.2的例子，然後執行第2個查詢的時候：
事務A再次執行查詢操作，複用老的Read View副本，Read View對應的值如下
| 變數 | 值 |
|---|---|
| m_ids | 100，101 |
| max_limit_id | 102 |
| min_limit_id | 100 |
| creator_trx_id | 100 |
然後再次回到版本鏈：從版本鏈中挑選可見的記錄：
從圖可得，最新版本的列name的內容是曹操，該版本的trx_id值為101。開始執行read view可見性規則校驗：
min_limit_id(100)=<trx_id（101）<max_limit_id（102);
因為m_ids{100,101}包含trx_id（101），
並且creator_trx_id (100) 不等於trx_id（101）
所以，trx_id=101這個記錄，對於當前事務是不可見的。這時候呢，版本鏈roll_pointer跳到下一個版本，trx_id=100這個記錄，再次校驗是否可見：
min_limit_id(100)=<trx_id（100）< max_limit_id（102);
因為m_ids{100,101}包含trx_id（100），
並且creator_trx_id (100) 等於trx_id（100）
所以，trx_id=100這個記錄，對於當前事務是可見的。即在可重複讀（RR）隔離級別下，複用老的Read View副本，解決了不可重複讀的問題。
連結：https://juejin.cn/post/7016165148020703246
來源：稀土掘金
著作權歸作者所有。商業轉載請聯絡作者獲得授權，非商業轉載請註明出處。