https://www.yuque.com/chenjiayang/blog/dozcqo
https://juejin.im/post/6844903778026536968
- 同一份数据临时保留多版本的一种方式,进而实现并发控制
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判断事务的执行先后顺序。
表格的隐藏列
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 的修改。

如果是第一次读,那还是可以读到之前其他事务提交的数据,不过没什么恶劣影响。

网友评论