一、MVCC解決了什麼問題？
主要解決的是多個事務并發引起的問題。
原本道理上來說讀寫和寫讀是不能并發的。但是如果不能并發的話，資料庫的效率就會非常低，是以才會引入MVCC。
本文結合以下連結及自己的驗證猜測得出的結論。并沒有看過源碼。
https://blog.csdn.net/LO_YUN/article/details/111319170
https://www.cnblogs.com/itZhy/p/8831947.html
請先了解readview和undolog版本鍊。
此外每次生成readview都會攜帶這幾個字段：
- m_ids：此時有哪些事務在MySQL中執行還沒送出
- min_trx_id：m_ids裡最小的值
- max_trx_id：MySQL下一個要生成的事務id，就是最大事務id
- creator_trx_id：目前你這個事務的id
每條資料都有兩條重要的隐藏字段：一個是trx_id，代表最近最近一次更新這條資料的事務id，另一個字段是roll_pointer，這個字段指向了這個實際undo log的復原日志。
我認為m_ids，min_trx_id，max_trx_id應該是指針類型的，指向同一條trx_id的這三個字段指向同一個位址（個人猜想，覺得這樣才解釋得通，如有時間，會好好找下相關文檔求證，現在假設是這樣的）
readview的生成時機
事務的隔離級别有四個：
- read uncommitted（讀未送出） ：解決髒寫
- read committed（讀已送出） ：解決髒讀
- repeatable read（可重複讀）：解決不可重複讀
- serializable（串行化）：解決幻讀
讀未送出和串行化使用很少。是以不做讨論（主要是它們也不需要readview）
在開啟事務的時候第一條sql語句就會生成readview。
在讀已送出的情況下，readivew生成的時機是，其它未送出的事務送出了。就會重新生成readview。
在可重複讀的情況下，readivew生成的時機是，自己需要寫行鎖。就會重新生成readview。
場景
下面隻讨論可重複讀的情況：
我們假設以下場景：
假設有張表：字段隻有id，sum。id是主鍵。有條記錄是（1，0）
此時我們開啟三個事務，操作如下。
我們假設目前的txid是100，事務A的txid是101，事務B的txid是102.事務C的txid是103
初始狀态：
執行①後：select * from test where id=1，找到的tx_id=101，sum=0
執行②後：update test set sum=sum + 10 where id = 1
執行③後：select * from test where id=1，找到的tx_id=101,sum=0
執行④後：select * from test where id=1，找到的tx_id=102,sum=10
執行⑤後： commit。
執行⑥後：select * from test where id=1，找到txid=101，sum=0
執行⑦後：update test set sum=sum + 10 where id = 1。會重新生成readview。
執行⑧後：select * from test where id=1 ，找到的txid=103.sum=10
執行⑨後：update test set sum=sum + 10 where id = 1，會一直阻塞擷取行鎖。
執行⑩後：commit。事務C的update就會更新readview。
執行⑪後：select * from test where id=1 ，找到txid=103，sum=30
這就是就是我了解的MVCC。其實就感覺像是每個事務存了一份快照，隻是觸發更新的快照的時間不一樣。
如有錯誤望指正！！！
感謝