InnoDB解决幻读方法和原理

首先说结论，在RR的隔离级别下，Innodb使用MVCC和next-key locks解决幻读，MVCC解决的是普通读（快照读）的幻读，next-key locks解决的是当前读情况下的幻读。

读取历史数据的方式，我们叫它快照读 (snapshot read)，而读取数据库当前版本数据的方式，叫当前读 (current read)。

• 快照读：就是select

  select * from table ….;

• 当前读：特殊的读操作，插入/更新/删除操作，属于当前读，处理的都是当前的数据，需要加锁。

  select * from table where ? lock in share mode;
  select * from table where ? for update;
  insert;
  update ;
  delete;

当前读

所谓当前读，指的是加锁的select(S或者X), update, delete等语句。在RR的事务隔离级别下，数据库会使用next-key locks来锁住本条记录以及索引区间。

比如：在RR的情况下，假设使用的是当前读，加锁了的读
select * from table where id>3 锁住的就是id=3这条记录以及id>3这个区间范围，锁住索引记录之间的范围，避免范围间插入记录，以避免产生幻影行记录。

普通读

因为普通读是不会加锁的读，故不会有next-key locks的使用，解决幻读的手段是MVCC

MVCC会给每行元组加一些辅助字段，记录创建版本号和删除版本号。

而每一个事务在启动的时候，都有一个唯一的递增的版本号。每开启一个新事务，事务的版本号就会递增。

默认的隔离级别（REPEATABLE READ）下，增删查改变成了这样：

• SELECT
  读取创建版本小于或等于当前事务版本号，并且删除版本为空或大于当前事务版本号的记录。这样可以保证在读取之前记录是存在的
• INSERT
  将当前事务的版本号保存至行的创建版本号
• UPDATE
  新插入一行，并以当前事务的版本号作为新行的创建版本号，同时将原记录行的删除版本号设置为当前事务版本号
• DELETE
  将当前事务的版本号保存至行的删除版本号

关键点是：读取的话，必须同时满足两个条件的

• 读取创建版本小于或等于当前事务版本号 这意味着数据在这个事务之前被创建
• 删除版本为空或大于当前事务版本号的记录。 这意味着删除操作在这个事务之后发生

在RC的模式下，MVCC解决不了幻读和不可重复读，因为每次读都会读它自己刷新的快照版本，简单来说就是另一个事务提交，他就刷新一次，去读最新的

在RR模型,我们虽然避免了幻读，但是存在一个问题，我们得到的数据不是数据中实时的数据，如果是对实时数据比较敏感的业务，这是不现实的。

例子：MySQL

事务的隔离级别实际上都是定义了当前读的级别，MySQL为了减少锁处理（包括等待其它锁）的时间，提升并发能力，引入了快照读的概念，使得select不用加锁。而update、insert这些“当前读”，就需要另外的模块来解决了。

比如，我们有以下的订单业务场景，我们队一个商品下单的操作，我们得首先检查这个订单的数量还剩多少，然后下单。

• 事务1:

  select num from t_goods where id=1;
  update t_goods set num=num-$mynum where id=1;

• 事务2：

  select num from t_goods where id=1;
  update t_goods set num=num-$mynum where id=1;

假设这个时候数量只有1，我们下单也是只有1.如果在并发的情况下，事务1查询到还有一单准备下单，但是这个时候事务2已经提交了。订单变成0.这个事务1在执行update，就会造成事故。

• 解决问题方法1(悲观锁)：就是利用for update对着个商品加锁，事务完成之后释放锁。切记where条件的有索引，否则会锁全表。

• 解决方法2(乐观锁)：给数据库表加上个version字段。然后SQL改写:

  select num,version from t_goods where id=1;
  update t_goods set num=num-1,version=verison+1 where id=1 and version=${version}

参考：
https://blog.csdn.net/qq_33330687/article/details/89004462
https://blog.csdn.net/a837199685/article/details/54563740?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.channel_param&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.channel_param