【SQL】MVCC 多版本并发控制
MVCC多版本并发控制
- 快照读与当前读
- 隔离级别
- 隐藏字段，undo log 版本链
-
- 隐藏字段trx_id
- 版本链
- read view
- 举例说明
-
- read committed（读已提交）隔离级别下
- repeatable read（可重复读）隔离级别下
- innodb如何解决幻读
- 总结
并发问题的解决办法：加锁或mvcc
读操作用mvcc，写操作加锁，读写不冲突，并发性好。mvcc的实现就是依赖于隐藏字段、undo log（多版本）、read view（控制）。
MySQL的存储引擎中，只有innodb支持mvcc。
快照读与当前读
不加锁的简单select读都是快照读，读的是历史数据。需要加锁的场景，读取的是记录的最新版本，加锁的select、对数据进行增删改都会进行当前读。
隔离级别
事务有四个隔离级别，可能存在三种并发问题：
MySQL中默认的隔离级别为可重复读，它实际上解决了脏读、不可重复读和幻读，但并不是串行化。
隐藏字段，undo log 版本链
隐藏字段trx_id
trx_id ：每次一个事务对某条聚簇索引记录进行改动时，都会把该事务的事务id赋值给trx_id 隐藏列。
roll_pointer ：每次对某条聚簇索引记录进行改动时，都会把旧的版本写入到undo日志中，然后这个隐藏列就相当于一个指针，可以通过它来找到该记录修改前的信息。
例如：
有一student表，id = 1，name = ‘张三’，class = ‘一班’
假设插入该记录的事务id为8，此条记录的结构如下：
版本链
每次对记录进行改动，都会记录一条undo日志，每条undo日志也都有一个roll_pointer 属性（ INSERT 操作对应的undo日志没有该属性，因为该记录并没有更早的版本），可以将这些undo日志都连起来，串成一个链表，就是版本链。
对该记录每次更新后，都会将旧值放到一条undo日志中，就算是该记录的一个旧版本，随着更新次数的增多，所有的版本都会被roll_pointer 属性连接成一个链表，我们把这个链表称之为版本链，版本链的头节点就是当前记录最新的值。
read view
readview就是事务A在使用MVCC机制进行快照读操作时产生的读视图。当事务启动时，会生成数据库系统当前的一个快照，innodb为每个事务构造了一个数组，用来记录并维护系统当前活跃（begin了但未commit）事务的id。
举例说明
mvcc只在read committed和repeatable read两个隔离级别下工作。
read committed（读已提交）隔离级别下
read committed：每次读取数据前都生成一个readview。
事务id的分配：如果是增删改行为，系统自动递增分配事务id；如果是查询行为，事务id为0.
现在有两个事务id 分别为10 、20 的事务在执行：
# Transaction 10
BEGIN;
UPDATE student SET name="李四" WHERE id=1;
UPDATE student SET name="王五" WHERE id=1;
# Transaction 20
BEGIN;
# 更新了一些别的表的记录
...
student表中id为1的记录得到的版本链表如图：
此时有个事务隔离级别为read committed，进行如下操作：
begin;
select * from student where id = 1;
因为transaction 10 未提交，所以这个事务查出来的结果是“1 张三 一班 8”这条记录。接下来解释原因：
- 在执行select操作时，生成read view，针对当前操作的快照，快照中记录了信息：creator_trx_id = 0（查询操作事务id为0）、trx_ids列表内容[10,20]（id为10和20的两个事务活跃）、up_limit_id = 10（小的事务是10）、low_limit_id = 21（最大的事务不会超过20）；
- 从版本链中挑选可见的记录，最新的是“王五”的记录，trx_id = 10，与creator_trx_id = 0不等，而且10在trx_ids列表中，表明10这个事务还没有提交，肯定不能查出；
- 接着找下一个版本，“李四”的trx_id 还是 10，也不行；
- 再往下找到“张三”trx_id = 8，不在活跃的事务列表里，一定是之前已经提交的事务，那么就把“张三”这条事务读出来。
接下来，把transaction 10的事务提交，
# Transaction 10
BEGIN;
UPDATE student SET name="李四" WHERE id=1;
UPDATE student SET name="王五" WHERE id=1;
COMMIT;
把transaction 20的事务中更新一下表student 中id 为1 的记录：
# Transaction 20
BEGIN;
# 更新了一些别的表的记录
...
UPDATE student SET name="钱七" WHERE id=1;
UPDATE student SET name="宋八" WHERE id=1;
此时版本链变成了这样：
接下来，事务又读了一次：
begin;
# select 1: 10 20 未提交
select * from student where id = 1; # 张三
# select 2: 10提交，20未提交
select * from student where id = 1; # 王五
- **在read committed隔离级别下，每读一次，生成一个read view。**所以第二次select的时候，又生成了一个read view。该readview的trx_ids列表内容剩[20]，up_limit_id = 20,low_limit_id = 21,creator_trx_id = 0;
- 从版本链中挑选，最新版本“宋八” trx_id = 20，还活跃着，就跳到下一个版本
- “钱七”的trx_id = 20，跳到下一版本
- "王五"的trx_id = 10，是提交过的，是生成read view之前的事务，所以查出这条记录。
repeatable read（可重复读）隔离级别下
只会在第一次查询时生成read view，之后的查询不会重复生成。
还是上面的例子：
# Transaction 10
BEGIN;
UPDATE student SET name="李四" WHERE id=1;
UPDATE student SET name="王五" WHERE id=1;
# Transaction 20
BEGIN;
# 更新了一些别的表的记录
...
此时有个事务隔离级别为read committed，进行如下操作：
begin;
select * from student where id = 1;
同上，此时查到的是“张三”记录。read view中：creator_trx_id = 0（查询操作事务id为0）、trx_ids列表内容[10,20]（id为10和20的两个事务活跃）、up_limit_id = 10（小的事务是10）、low_limit_id = 21（最大的事务不会超过20）；
提交transaction 10，到transaction 20中更新表student，
# Transaction 20
BEGIN;
# 更新了一些别的表的记录
...
UPDATE student SET name="钱七" WHERE id=1;
UPDATE student SET name="宋八" WHERE id=1;
在这个场景下，刚才读过的事务现在又读了一次：
begin;
# select 1: 10 20 未提交
select * from student where id = 1; # 张三
# select 2: 10提交，20未提交
select * from student where id = 1; # 张三
这时不再生成新的read view，还是一开始的read view。creator_trx_id = 0（查询操作事务id为0）、trx_ids列表内容[10,20]（id为10和20的两个事务活跃）、up_limit_id = 10（小的事务是10）、low_limit_id = 21（最大的事务不会超过20）；
- 版本链中最新的版本“宋八” trx_id = 20，是活跃的事务，跳过；
- “钱七” trx_id = 20，活跃的事务，跳过； （这两个是transaction 20中的更新，未提交）
- “王五” trx_id = 10，活跃的事务，跳过； （这是transaction 10 中的更新，已经提交，但此时的read view是首次select时生成的，所以认为transaction 10 还在活跃）
- “李四” trx_id = 10，活跃的事务，跳过；
- “张三” trx_id = 8，不在trx_ids列表中，查出。
所以说，只要查询事务没有提交，用的都是第一次select时生成的read view。
innodb如何解决幻读
幻读：student表中有一条id=1的记录，事务A开始进行第一次查询，结果显示id=1，现有事务B对student表进行更新操作，添加了id=2，id=3的两条记录并提交，接下来事务A再进行第二次查询，结果显示id=1，id=2，id=3，同一事务A前后两次查询操作的返回结果不相同，这就是出现了幻读。
在repeatable read隔离级别下，read view只在事务第一次进行查询操作时生成，此后的查询操作（只要不commit）仍用这个视图，所以就算事务B提交了更新，read view并不同步更新，trx_ids列表中仍有事务B的trx_id，认为事务B处于活跃状态，跳过更新的那条记录。
总结
MVCC = 隐藏字段 trx_id + undo log 版本链 + read view 快照
READ COMMITTD 在每一次进行普通SELECT操作前都会生成一个ReadView。
REPEATABLE READ 只在第一次进行普通SELECT操作前生成一个ReadView，之后的查询操作都重复使用这个ReadView。
说明：执行delete语句或更新主键的update语句并不会立即把对应的记录完全从页面中删除，而是执行一个所谓的delete mark操作，相当于只是对记录上打了一个删除标志位，这就是为MVCC服务的，因为可能需要回滚。