https://www.yuque.com/chenjiayang/blog/dozcqo
https://juejin.im/post/6844903778026536968
同一份数据临时保留多版本的一种方式，进而实现并发控制（CAS更高效）
版本号一对一，对应事务的版本号
快照读基于undo log实现，只要记录快照的版本号即可，速度很快。
当前读通过上锁实现，innodb通过next-key算法（行锁+间隙锁）为我们将这块区域锁上了，所以事务B无法对其修改。
MVCC是MySQL中基于乐观锁理论（基于版本号的CAS）实现隔离级别的方式，用于实现读已提交和可重复读取隔离级别的实现。有提交读（RC）和可重复读（RR）这两种隔离级别。
MVCC 多版本控制实现读取数据不用加锁， 可以让读取数据同时修改。修改数据时同时可读取。
MVCC通过保存数据的历史版本，根据比较版本号来处理数据的是否显示，从而达到读取数据的时候不需要加锁就可以保证事务隔离性的效果。
- 旧版本保存在undo log中，提交了就可以删除
- 什么是多版本？
MVCC 数据库需要更新一条数据记录的时候，它不会直接用新数据覆盖旧数据，而是将旧数据标记为过时（obsolete）并在别处增加新版本的数据。这样就会有存储多个版本的数据，但是只有一个是最新的。这种方式允许读者读取在他读之前已经存在的数据，即使这些数据在读的过程中半路被别人修改、删除了，也对先前正在读的用户没有影响。这种多版本的方式避免了填充删除操作在内存和磁盘存储结构造成的开销，但是需要系统周期性整理（sweep through）以删除老的、过时的数据。（写不需要覆盖原数据不影响读）
- 快照读与当前读
快照读：select xxx from xxx
当前读：
(1) select xxx from xxx for update
(2) select xxx from xxx lock in share mode
(3) update/insert/delete
可见，快照读仅针对裸的select
事务版本号与快照原理
每次事务开启前都会从数据库获得一个自增长的事务ID，可以从事务ID判断事务的执行先后顺序。
如果一个库有 100G，那么我启动一个事务，MySQL 就要拷贝 100G 的数据出来，这个过程得多慢啊？可是，我平时的事务执行起来很快啊。
实际上，我们并不需要拷贝出这 100G 的数据。
InnoDB 里面每个事务有一个唯一的事务 ID，叫作 transaction id。它是在事务开始的时候向 InnoDB 的事务系统申请的，是按申请顺序严格递增的。
而每行数据也都是有多个版本的。每次事务更新数据的时候，都会生成一个新的数据版本，并且把 transaction id 赋值给这个数据版本的事务 ID，记为 row trx_id。同时，旧的数据版本要保留，并且在新的数据版本中，能够有信息可以直接拿到它。
也就是说，数据表中的一行记录，其实可能有多个版本 (row)，每个版本有自己的 row trx_id。
表格的隐藏列
DB_TRX_ID: 记录操作该数据事务的事务ID；
DB_ROLL_PTR：指向上一个版本数据在undo log 里的位置指针；
DB_ROW_ID: 隐藏ID ，当创建表没有合适的索引作为聚集索引时，会用该隐藏ID创建聚集索引;
| id | name | 创建时的ID (DB_TRX_ID) | 删除时的ID (DB_ROLL_PT) |
|---|---|---|---|
| 1 | yang | 1 | undefined |
| 2 | long | 1 | undefined |
| 3 | fei | 1 | undefined |
MVCC下的CRUD
初始列表：
| id | test_id | DB_TRX_ID | DB_ROLL_PT |
|---|---|---|---|
| 5 | 68 | 1 | NULL |
| 6 | 78 | 1 | NULL |
- MVCC逻辑流程 - 删除 DELETE
begin；--获得全局事务ID = 3
delete test_zq where id = 6;
commit;
执行完上述SQL之后数据并没有被真正删除，而是对删除版本号做改变，如下所示：
| id | test_id | DB_TRX_ID | DB_ROLL_PT |
|---|---|---|---|
| 5 | 68 | 1 | NULL |
| 6 | 78 | 1 | 3 |
- MVCC逻辑流程 - 修改 UPDATE
先置为删除再插入新的
begin;-- 获取全局系统事务ID 假设为 10
update test_zq set test_id = 22 where id = 5;
commit;
| id | test_id | DB_TRX_ID | DB_ROLL_PT |
|---|---|---|---|
| 5 | 68 | 1 | 10 |
| 6 | 78 | 1 | 3 |
| 5 | 22 | 10 | NULL |
- MVCC逻辑流程 - 查询 SELECT
- 查找数据行版本号早于等于当前事务版本号的数据行记录（比我早的事务）
也就是说，数据行的版本号要小于或等于当前是事务的系统版本号，这样也就确保了读取到的数据是当前事务开始前已经存在的数据，或者是自身事务改变过的数据。
- 查找删除版本号要么为NULL，要么大于当前事务版本号的记录（要么没删，要么删的比本事务晚）
这样确保查询出来的数据行记录在事务开启之前没有被删除
begin;-- 假设拿到的系统事务ID为 12
select * from test_zq;
commit;
| id | test_id | DB_TRX_ID | DB_ROLL_PT |
|---|---|---|---|
| 6 | 22 | 10 | NULL |
RC和RR的区别（主要还是解决脏读）
- RC（read commit）级别（当前读）
RC（read commit）级别下同一个事务里面的每一次查询都会获得一个新的read view副本。这样就可能造成同一个事务里前后读取数据可能不一致的问题（重复读）
- RR（repeatable read）级别（快照读）
RR级别下的一个事务里只会获取一次read view副本，从而保证每次查询的数据都是一样的。
事务 A 第一条 SELECT 语句在事务 B 更新数据前，因此生成的 ReadView 在事务 A 过程中不发生变化，即使事务 B 在事务 A 之前提交，但是事务 A 第二条查询语句依旧无法读到事务 B 的修改。
事务 A 的第一条 SELECT 语句在事务 B 的修改提交之后，因此可以读到事务 B 的修改。但是注意，如果事务 A 的第一条 SELECT 语句查询时，事务 B 还未提交，那么事务 A 也查不到事务 B 的修改。
如果是第一次读，那还是可以读到之前其他事务提交的数据，不过没什么恶劣影响。
快照的区别:
READ COMMITTD在每一次进行普通SELECT操作前都会生成一个ReadView（可重复读，要求从事务开始的时候），而REPEATABLE READ只在第一次进行普通SELECT操作前生成一个ReadView，之后的查询操作都重复这个ReadView就好了。
修改不会影响到快照里的值。
