Innodb-MVCC詳解
借用高性能 MySQL 的幾句話
MySQL 的大多數(shù)事務(wù)型存儲引擎都不是簡單的行級鎖，基于提升并發(fā)性能考慮亥曹，他們一般都同時實現(xiàn)了多版本并發(fā)控制 MVCC酌毡，但各自的實現(xiàn)機制不盡相同，因為 MVCC 沒有一個統(tǒng)一的實現(xiàn)標準。
可以認為 MVCC 是行級鎖的一個變種告材，但是他在很多情況下避免了枷鎖操作，因此開銷更低古劲，雖然實現(xiàn)機制有所不同斥赋，但大都實現(xiàn)了非阻塞的讀操作，寫操作也只鎖定必要的行产艾。
我們先來分析為什么個大多數(shù)據(jù)庫都實現(xiàn)了 MVCC 以及實現(xiàn)的好處
項目日常運行中絕大部分的是查詢語句疤剑，如果實現(xiàn)的方式是讀鎖(共享鎖)的方式那么，在大量讀的情況下需要去阻塞寫操作闷堡，如果涉及到了部分寫操作隘膘，大量的鎖爭用問題，可能會導(dǎo)致讀寫操作無法獲得鎖去執(zhí)行杠览。
如果讀不用加鎖弯菊，那么對于系統(tǒng)的吞吐量一定是海量的提升。
寫操作 (insert/update/delete)踱阿，lock 等操作施加最小級別的鎖管钳，依次為主鍵行鎖、唯一索引+主鍵行鎖软舌、間隙鎖蹋嵌、范圍鎖、全表主鍵鎖葫隙。當在其吞吐量較高的情況下栽烂，施加不同的鎖對于系統(tǒng)的性能影響都比較大，需要考驗開發(fā)者的一個技術(shù)水平恋脚。
再來借用高性能 MySQL 的幾句話
MVCC 的實現(xiàn)是通過某個時間點的快照來實現(xiàn)的
是通過在每行記錄后面保存系統(tǒng)版本號來實現(xiàn)的腺办，每開啟一個事務(wù)，系統(tǒng)版本號遞增并且將值賦值給事務(wù)版本號糟描，然后查詢的時候只會去查找行的版本號早于當前事務(wù)版本號的行...
在這個地方怀喉，因為 它沒有仔細的介紹，相信有的讀者可能會有一些問題船响，如下:
某個時間的快照是什么躬拢，是一個完整的復(fù)制的鏡像文件躲履，還是 mvcc 實現(xiàn)，還是數(shù)據(jù)庫數(shù)據(jù)備份等等聊闯？
既然有了當前事務(wù)的快照了工猜，那么讀取的數(shù)據(jù)肯定是當前時間點事務(wù)的快照數(shù)據(jù)，為什么還需要 根據(jù)什么系統(tǒng)版本號菱蔬，事務(wù)版本號篷帅，行版本號去 curd 數(shù)據(jù)呢？
通過下來分析你就會明白了
Innodb拴泌，MVCC 的讀可以分為2種魏身，快照讀，當前讀蚪腐，這里只介紹 RR 隔離界別
在這之前我們先來了解幾個概念便于我們理解
首先
Innodb 會為每一行數(shù)據(jù)添加3個字段分別是
DATA_TRX_ID
表示當前事務(wù)遞增得到的事務(wù)id作為其行版本號DATA_ROLL_PTR
一個指向 undo 信息的指針箭昵，undo 就是實現(xiàn) mvcc 的關(guān)鍵，等等會介紹回季。DELETED_BIT
標識該記錄是否被刪除
其次
我們要注意的一個地方就是家制，快照的創(chuàng)建默認是在你執(zhí)行第一條 SQL 語句的時候，事務(wù)的真正開啟也在這個時候茧跋，我們這里的講解默認開啟事務(wù)就創(chuàng)建快照即執(zhí)行了 start transaction with consistent snapshot;
undo
在 mvcc 中，當用戶讀取一條記錄的時候卓囚，若此記錄已經(jīng)被其它事務(wù)占用瘾杭，當前事務(wù)就可以通過undo log 讀取之前的行的版本信息，找到行版本號小于等于當前事務(wù)版本號的數(shù)據(jù)哪亿。以及讀取到一條被標識為刪除的數(shù)據(jù)的時候粥烁，也可以通過undo log 來獲取之前版本正常的數(shù)據(jù)。這里不理解的話沒有關(guān)系蝇棉，看完下面的內(nèi)容再來看這句話就明白了讨阻。
快照讀
快照數(shù)據(jù)就是當前行數(shù)據(jù)之前的歷史版本，每行記錄都可能有多個版本篡殷，每一行記錄也可能同時存在多個快照數(shù)據(jù)钝吮。所以稱之為 多版本并發(fā)控制 MVCC，每個事務(wù)開啟的時候都會創(chuàng)建一個 read view板辽，它定義在 readOread.h 文件中奇瘦，用來檢索行的可見性
dulint low_limit_id; // 當前開啟事務(wù)的 id，每開啟一個事務(wù)系統(tǒng)版本號遞增并且賦值給事務(wù)系統(tǒng)版本號
dulint up_limit_id; // 當前活躍事務(wù)最小的事務(wù) id
ulint n_trx_ids; // 當前活躍事務(wù) id 的數(shù)量
dulint* trx_ids; // 當前活躍事務(wù)的 id 列表
每開啟一個事務(wù)的時候和已經(jīng)存在的事務(wù)的記錄的一個記錄
我們假設(shè)現(xiàn)目前用戶 A 開啟了一個事務(wù) id 為 10劲弦，目前存在事務(wù) 9耳标、8、7邑跪、6 即
low_limit_id = 10;
up_limit_id = 6
n_trx_ids = 5
trx_ids = [6,7,8,9,10]
用戶 B 開啟事務(wù)的時候 id 為 9, 存在事務(wù) 8次坡、7呼猪、6
low_limit_id = 9;
up_limit_id = 6
n_trx_ids = 4
trx_ids = [6,7,8,9]
然后我們先分析 select 的幾種情況
select
比如當前處于用戶 B
只會檢索行的系統(tǒng)版本號小于等于當前事務(wù)的版本號保證數(shù)據(jù)是在事務(wù)開啟之前就已經(jīng)提交了了的或者是自己插入的。
也就是必須 < 6 (up_limit _id) 的行的版本號才是可見的
同理對于用戶 A 來說必須是 < 6 的行的系統(tǒng)版本號才是可見的insert/update/delete 屬于當前讀砸琅，下面介紹
當前讀
select ... lock in share mode
select ... for update
insert
update
delete
當前讀不同于快讀的地方是宋距，當前讀讀取的是系統(tǒng)最新的數(shù)據(jù)，它首先回去獲取鎖明棍，獲取到鎖后執(zhí)行對應(yīng)的上述操作乡革，事務(wù)完成后再釋放鎖不是修改完成后。如果這個時間段存在其它的事務(wù)當前讀那么久會阻塞其它事務(wù)摊腋。那么如果這個地方的更新不是主鍵或者唯一索引級別的話會涉及到幻讀沸版，它是采用了間隙鎖（next-key locking）策略防止幻讀的出現(xiàn)。
