RR和RC使用场景

RR 可重复读，大事务中嵌套小事务，第一个小事务写数据后，后面的小事务不能读到同一个大事务下大上一个小事务的写入。
比如以最后一条数据修订数据为准时的情况，如一位老师对一位学生作业从开始到批改后改分的一个列表，会以最后的为准时，这种不太在意中间改动分数，只在意学生改完一版作业后的最后成绩，中间成绩是历史成绩，如果业务不需要记录，那更新学生成绩到最新的即可:

update student set score=#{currentScore} where s_id = 3;

RC 读提交，大事务中嵌套小事务，小事务每个都可以读到前一个事物的修改后的值。
比如在一个积分系统里，用户的积分是需要累加的，假如用户积分也是列表在外部传入到数据库后，每一个值其实都是重要的，
虽然可能只更改这一个用户的积分，但业务可能是类似要将上一个积分用于累计的形式：

update user set score=score+#{oneScore} where user_id = 3;

引用：

MySQL的RR需要gap lock来解决幻读问题。而RC隔离级别则是允许存在不可重复读和幻读的。所以RC的并发一般要好于RR；

RR隔离级别，通过 where 条件走非索引列过滤之后，即使不符合where条件的记录，也是会加行锁。所以从锁方面来看，RC的并发应该要好于RR；可以减少一部分锁竞争，减少死锁和锁超时的概率。

读提交(Read Committed)

1. 数据库领域，事务隔离级别的一种，简称RC
2. 它解决“读脏”问题，保证读取到的数据行都是已提交事务写入的
3. 它可能存在“读幻影行”问题，同一个事务里，连续相同的read可能读到不同的结果集

可重复读(Repeated Read)

1. 数据库领域，事务隔离级别的一种，简称RR
2. 它不但解决“读脏”问题，还解决了“读幻影行”问题，同一个事务里，连续相同的read读到相同的结果集

RR下，大事务嵌套几个小事务，第一个小事务写操作提交后，后面的小事务不能读取到第一个小事务提交的内容；
RC下，大事务嵌套几个小事务，第一个小事务写操作提交后，后面的小事务可以读取到第一个小事务提交的内容；