✅为什么默认RR，大厂要改成RC？
虽然RR的隔离级别可以在一定程度上避免脏读、不可重复读和幻读等问题，但是，对于很多大型的互联网来说，会愿意将数据库的默认隔离级别调整成并发度更高的RC级别，从而，提升并发度并且降低发生死锁的概率。
扩展知识
RR 和 RC 的区别
我们需要先来弄清楚一下 RR 和 RC 的区别，分析下各自的优缺点。
一致性读
一致性读，又称为快照读。快照即当前行数据之前的历史版本。快照读就是使用快照信息显示基于某个时间点的查询结果，而不考虑与此同时运行的其他事务所执行的更改。
在MySQL 中，只有READ COMMITTED 和 REPEATABLE READ这两种事务隔离级别才会使用一致性读。
在 RR 中，快照会在事务中第一次SELECT语句执行时生成，只有在本事务中对数据进行更改才会更新快照。
在 RC 中，每次读取都会重新生成一个快照，总是读取行的最新版本。
在数据库的 RC 这种隔离级别中，还支持"半一致读" ，一条update语句，如果 where 条件匹配到的记录已经加锁，那么InnoDB会返回记录最近提交的版本，由MySQL上层判断此是否需要真的加锁。
锁机制
数据库的锁，在不同的事务隔离级别下，是采用了不同的机制的。在 MySQL 中，有三种类型的锁，分别是Record Lock、Gap Lock和 Next-Key Lock。
Record Lock表示记录锁，锁的是索引记录。
Gap Lock是间隙锁，锁的是索引记录之间的间隙。
Next-Key Lock是Record Lock和Gap Lock的组合，同时锁索引记录和间隙。他的范围是左开右闭的。
在 RC 中，只会对索引增加Record Lock，不会添加Gap Lock和Next-Key Lock。
在 RR 中，为了解决幻读的问题，在支持Record Lock的同时，还支持Gap Lock和Next-Key Lock；
主从同步
在数据主从同步时，不同格式的 binlog 也对事务隔离级别有要求。
MySQL的binlog主要支持三种格式，分别是statement、row以及mixed，但是，RC 隔离级别只支持row格式的binlog。如果指定了mixed作为 binlog 格式，那么如果使用RC，服务器会自动使用基于row 格式的日志记录。
而 RR 的隔离级别同时支持statement、row以及mixed三种。
为什么互联网公司选择使用 RC
提升并发
互联网公司和传统企业最大的区别是什么？
高并发！
没错，互联网业务的并发度比传统企业要高出很多。2020年双十一当天，订单创建峰值达到 58.3 万笔/秒。
很多人问，要怎么做才能扛得住这么大的并发量。其实，这背后的优化多到几个小时都讲不完，因为要做的、可以做的事情实在是太多了。
而有一个和我们今天这篇文章有关的优化，那就是通过修改数据库的隔离级别来提升并发度。
为什么 RC 比 RR 的并发度要好呢？
首先，RC 在加锁的过程中，是不需要添加Gap Lock和 Next-Key Lock 的，只对要修改的记录添加行级锁就行了。
这就使得并发度要比 RR 高很多。
另外，因为 RC 还支持"半一致读"，可以大大的减少了更新语句时行锁的冲突；对于不满足更新条件的记录，可以提前释放锁，提升并发度。
减少死锁
因为RR这种事务隔离级别会增加Gap Lock和 Next-Key Lock，这就使得锁的粒度变大，那么就会使得死锁的概率增大。
死锁：一个事务锁住了表A，然后又访问表B；另一个事务锁住了表B，然后企图访问表A；这时就会互相等待对方释放锁，就导致了死锁。
RR和RC主要在加锁机制、主从同步以及一致性读方面存在一些差异。
而很多大厂，为了提升并发度和降低死锁发生的概率，会把数据库的隔离级别从默认的 RR 调整成 RC。
当然，这样做也不是完全没有问题，首先使用 RC 之后，就需要自己解决不可重复读的问题，这个其实还好，很多时候不可重复读问题其实是可以忽略的，或者可以用其他手段解决。
比如读取到别的事务修改的值其实问题不太大的，只要修改的时候的不基于错误数据就可以了，所以我们都是在核心表中增加乐观锁标记，更新的时候都要带上锁标记进行乐观锁更新。
还有就是使用 RC 的时候，不能使用statement格式的 binlog，这种影响其实可以忽略不计了，因为MySQL是在5.1.5版本开始支持row的、在5.1.8版本中开始支持mixed，后面这两种可以代替 statement格式。
总结
所有的技术方案的选择，都是一种权衡的艺术！