[【MySQL】当前读、快照读、MVCC]

当前读:****

　　select...lock in share mode (共享读锁)
select...for update
update , delete , insert

　　当前读, 读取的是最新版本, 并且对读取的记录加锁, 阻塞其他事务同时改动相同记录，避免出现安全问题。

　　例如，假设要update一条记录，但是另一个事务已经delete这条数据并且commit了，如果不加锁就会产生冲突。所以update的时候肯定要是当前读，得到最新的信息并且锁定相应的记录。

当前读的实现方式：next-key锁( 行记录锁+ Gap间隙锁)****

 　　间隙锁： 只有在Read Repeatable、Serializable隔离级别才有，就是锁定范围空间的数据，假设id有3,4,5，锁定id>3的数据，是指的4，5及后面的数字都会被锁定， 因为此时如果不锁定没有的数据，例如当加入了新的数据id=6，就会出现幻读，间隙锁避免了幻读。 　　1.对主键或唯一索引，如果当前读时，where条件全部精确命中(=或者in)，这种场景本身就不会出现幻读，所以只会加行记录锁。 　　2.没有索引的列，当前读操作时，会加全表gap锁，生产环境要注意。 　　3.非唯一索引列，如果where条件部分命中(>、<、like等)或者全未命中，则会加附近Gap间隙锁。例如，某表数据如下，非唯一索引2,6,9,9,11,15。如下语句要操作非唯一索引列9的数据，gap锁将会锁定的列是(6,11]，该区间内无法插入数据。

快照读****

　　单纯的select操作，不包括上述 select ... lock in share mode, select ... for update。　　　　 　　Read Committed隔离级别：每次select都生成一个快照读。 　　Read Repeatable隔离级别：开启事务后第一个select语句才是快照读的地方，而不是一开启事务就快照读。

快照读的实现方式：u ndolog和多版本并发控制MVCC****

　下图右侧绿色的是数据：一行数据记录，主键ID是10，name='Jack'，age=10,  被update更新set为name= 'Tom'，age=23。

　　事务会先使用“排他锁”锁定改行，将该行当前的值复制到undo log中，然后再真正地修改当前行的值，最后填写事务的DB_TRX_ID，使用回滚指针DB_ROLL_PTR指向undo log中修改前的行DB_ROW_ID。

　 DB_TRX_ID: 6字节DB_TRX_ID字段，表示最后更新的事务id(update,delete,insert)。此外，删除在内部被视为更新，其中行中的特殊位被设置为将其标记为已软删除。 　　DB_ROLL_PTR: 7字节回滚指针，指向前一个版本的undolog记录，组成undo链表。如果更新了行，则撤消日志记录包含在更新行之前重建行内容所需的信息。
DB_ROW_ID: 6字节的DB_ROW_ID字段，包含一个随着新行插入而单调递增的行ID, 当由innodb自动产生聚集索引时，聚集索引会包括这个行ID的值，否则这个行ID不会出现在任何索引中。如果表中没有主键或合适的唯一索引, 也就是无法生成聚簇索引的时候, InnoDB会帮我们自动生成聚集索引, 聚簇索引会使用DB_ROW_ID的值来作为主键; 如果表中有主键或者合适的唯一索引, 那么聚簇索引中也就不会包含 DB_ROW_ID了 。 **  　　其它：insert undo log只在事务回滚时需要, 事务提交就可以删掉了。update undo log包括update 和 delete , 回滚和快照读 都需要。

今天pptv电面的时候，与面试官在innodb中幻读的解决到底是依赖间隙锁还是mvcc产生了分歧。
双方各执己见 。。。（事务隔离级别rr）面试官大大认为innodb就是靠mvcc解决的幻读，而我固执的认为绝对是间隙锁解决了这个问题。

面毕，查了一些资料，并且自己时间之后的分析和结论如下。

首先读分为：
快照读
select * from table where ?;

当前读：特殊的读操作，插入/更新/删除操作，属于当前读，需要加锁。
select * from table where ? lock in share mode;
select * from table where ? for update;
insert into table values (…);
update table set ? where ?;
delete from table where ?;

对于快照读来说，幻读的解决是依赖mvcc解决。而对于当前读则依赖于gap-lock解决。

 

 

 

 

 

 

 

 

 

MySQL最牛的RR隔离级别，是如何基于ReadView机制实现的？****

 

Mr'Sui 2020-12-28 10:30:18  141  收藏

分类专栏： MySQL 随笔记 文章标签： mysql 数据库

版权

MySQL中最牛的RR隔离级别，是如何同时避免不可重复读问题和幻读问题的。

 

在MySQL中让多个事务并发运行的时候能够互相隔离，避免同时读写一条数据的时候有影响，是依托undo log版本链条和ReadView机制来实现的。

 

基于ReadView机制可以实现RC隔离级别，即每次查询的时候都生成一个ReadView，这样的话，只要在这次查询之前有别的事务提交了，那么别的事务更新的数据，是可以看到的。

 

那么如果是RR级别呢？RR级别下，这个事务读一条数据，无论读多少次，都是一个值，别的事务修改数据之后哪怕提交了，也是看不到人家修改的值的，这就避免了不可重复读的问题。同时如果别的事务插入了一些新的数据，也是读不到的，这样就可以避免幻读的问题。

 

首先假设有一条数据是事务id=50的一个事务插入的，同时此时有事务A和事务B同时在运行，事务A的id是60，事务B的id是70，如下图所示：

 

 

 

这个时候，事务A发起了一个查询，它就是第一次查询就会生成一个ReadView，此时ReadView里的creator_trx_id是60，min_trx_id是60，max_trx_id是71，m_ids是[60, 70]，此时ReadView如下图所示：

 

 

 

这个时候事务A基于这个ReadView去查这条数据，会发现这条数据的trx_id为50，是小于ReadView里的min_trx_id的，说明它发起查询之前，早就有事务插入这条数据还提交了，所以此时可以查到这条原始值的，如下图：

 

 

 

接着就是事务B此时更新了这条数据的值为值B，此时会修改trx_id为70，同时生成一个undo log，而且关键是事务B此时它还提交了，也就是说此时事务B已经结束了，如下图所示：

 

 

 

思考一个问题，ReadView中的m_ids此时还会是60和70吗？

 

那必然是的，因为ReadView一旦生成了就不会改变了，这个时候虽然事务B已经结束了，但是事务A的ReadView里，还是会有60和70两个事务id。意思其实就是，在事务A开启查询的时候，事务B当时是在运行的，就是这个意思。

 

接着此时事务A去查询这条数据的值，会惊讶的发现此时数据的trx_id是70了，70一方面是在ReadView的min_trx_id和max_trx_id的范围区间的，同时还在m_ids列表中。说明起码是事务A开启查询的时候，id为70的这个事务B还是在运行的，然后由这个事务B更新了这条数据，所以此时事务A是不能查询到事务B更新的这个值的，因此这个时候继续顺着指针往历史版本链条上去找，如下图：

 

 

 

接着事务A顺着指针找到下面一条数据，trx_id为50，是小于ReadView的min_trx_id的，说明在它开启查询之前，就已经提交了这个事务了，所以事务A是可以查询到这个值的，此时事务A查到的是原始值，如下图：

 

 

 

接着来看看幻读的问题它是如何解决的。假设现在事务A先用select * from x where id>10来查询，此时可能查到的就是一条数据，而且读到的是这条数据的原始值的那个版本，至于原因，上面都解释过了，如下图：

 

 

 

现在有一个事务C插入了一条数据，然后提交了，此时如下图所示：

 

 

 

接着，此时事务A再次查询，此时会发现符合条件的有2条数据，一条是原始值那个数据，一条是事务C插入的那条数据，但是事务C插入的那条数据的trx_id是80，这个80是大于自己的ReadView的max_trx_id的，说明是自己发起查询之后，这个事务才启动的，所以此时这条数据是不能查询的。

 

因此事务A本次查询，还是只能查到原始值一条数据，如下图：

 

 

 

在这里，事务A根本不会发生幻读，它根据条件范围查询的时候，每次读到的数据都是一样的，不会读到人家插入进去的数据，这都是依托ReadView机制实现的！