首先说结论，在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