innodb mvcc

mvcc 多版本并發控制
在RR isolution 情況下 trx在啟動的時候就拍了個快照。這個快照是基于整個數據庫的。
其實這個快照并不是說拷貝整個數據庫。并不是說要拷貝出這100個G的數據。

innodb里面每個trx有一個唯一的trxID 叫做trx id .在trx 開始的時候向innodb系統申請。嚴格按照申請順序increment。

而每行數據都是有多個版本。每次trx 更新數據的時候，都會生成一個新的數據版本。并且把trx id賦給這個數據版本的trx id .記錄為row trx_id .同時 舊的數據版本要保留。并且在新的數據版本中 能夠直接拿到。

也就是說數據表中的一行記錄 其實可能有多個版本。每個版本有自己的ID。

這里v1-v4 都是同一行數據的4個版本。當前最新的版本v4 k=4 是被trxid 40的事務更新。因此她的row trx_id = 25.

這里其實有undo的參與。在sql1 2 3的情況下。而且v1 v2 v3并不是物理情況下存在的。而是通過undo直接計算出來的。

在知道mvcc和row trxid 的概念下。上面說的innodb 的快照的概念。

按照RR的概念 當我這個事務啟動的時候 能夠看到所有已提交的事務。但是 這個事務執行的時候 其他事務的更新對他不可見。

因此 一個事務只需要在啟動的時候說: 以我啟動的時候為準。如果一個數據版本是我啟動之前生成的，就認。如果是我啟動之后生成的。就不認。我必須找到她的上一個版本。當然如果上一個也不可見 再往前找 找到認的為止。

從代碼看實現 就是innodb 構建了一個Array 用來保存這個事務啟動的時候。當前引擎正在活動的所有事務ID。活動的概念就是 啟動了但是還