我们知道，我们可以通过这个命令查看数据库当前的隔离级别，MySQL 默认隔离级别是RR.
select @@tx_isolation;ANSI/ISO SQL定义的标准隔离级别有四种，从高到底依次为：可序列化(Serializable)、可重复读(Repeatable Reads)、提交读(Read Committed)、未提交读(Read Uncommitted)。
- RU隔离级别下，可能发生脏读、幻读、不可重复读等问题。
未提交读的数据库锁情况（实现原理）
事务在读数据的时候并未对数据加锁。
事务在修改数据的时候只对数据增加行级共享锁。
- RC隔离级别下，解决了脏读的问题，存在幻读、不可重复读的问题。
提交读的数据库锁情况
事务对当前被读取的数据加 行级共享锁（当读到时才加锁），一旦读完该行，立即释放该行级共享锁；
事务在更新某数据的瞬间（就是发生更新的瞬间），必须先对其加 行级排他锁，直到事务结束才释放。
- RR隔离级别下，解决了脏读、不可重复读的问题，存在幻读的问题。
可重复读的数据库锁情况
事务在读取某数据的瞬间（就是开始读取的瞬间），必须先对其加 行级共享锁，直到事务结束才释放；
事务在更新某数据的瞬间（就是发生更新的瞬间），必须先对其加 行级排他锁，直到事务结束才释放。
- Serializable隔离级别下，解决了脏读、幻读、不可重复读的问题。
可序列化的数据库锁情况
事务在读取数据时，必须先对其加 表级共享锁 ，直到事务结束才释放；
事务在更新数据时，必须先对其加 表级排他锁 ，直到事务结束才释放。
虽然可序列化解决了脏读、不可重复读、幻读等读现象。但是序列化事务会产生以下效果：
1.无法读取其它事务已修改但未提交的记录。
2.在当前事务完成之前，其它事务不能修改目前事务已读取的记录。
3.在当前事务完成之前，其它事务所插入的新记录，其索引键值不能在当前事务的任何语句所读取的索引键范围中。
这四种隔离级别是ANSI/ISO SQL定义的标准定义的，我们比较常用的MySQL对这四种隔离级别是都支持的。
Oracle默认的隔离级别是 RC，而MySQL默认的隔离级别是 RR。那么，你知道为什么吗？
Oracle 的隔离级别
前面我们说过，Oracle只只支持ANSI/ISO SQL定义的Serializable和Read Committed，其实，根据Oracle官方文档给出的介绍，Oracle支持三种隔离级别：
即Oracle支持Read Committed、Serializable和Read-Only。
Read-Only只读隔离级别类似于可序列化隔离级别，但是只读事务不允许在事务中修改数据，除非用户是SYS。
在Oracle这三种隔离级别中，Serializable和Read-Only显然都是不适合作为默认隔离级别的，那么就只剩Read Committed这个唯一的选择了。
MySQL 的隔离级别
在MySQL设计之处，他的定位就是提供一个稳定的关系型数据库。而为了要解决MySQL单点故障带来的问题，MySQL采用主从复制的机制。
所谓主从复制，其实就是通过搭建MySQL集群，整体对外提供服务，集群中的机器分为主服务器（Master）和从服务器（Slave），主服务器提供写服务，从服务器提供读服务。
为了保证主从服务器之间的数据的一致性，就需要进行数据同步.
MySQL在主从复制的过程中，数据的同步是通过bin log进行的，简单理解就是主服务器把数据变更记录到bin log中，然后再把bin log同步传输给从服务器，从服务器接收到bin log之后，再把其中的数据恢复到自己的数据库存储中。
那么，binlog里面记录的是什么内容呢？格式是怎样的呢？
MySQL的bin log主要支持三种格式，分别是statement、row以及mixed。MySQL是在5.1.5版本开始支持row的、在5.1.8版本中开始支持mixed。
statement和row最大的区别，当binlog的格式为statemen时，binlog 里面记录的就是 SQL 语句的原文（这句话很重要！！！后面会用的到）。
关于这几种格式的区别，就不在这里详细展开了，之所以要支持row格式，主要是因为statement格式中存在很多问题，最明显的就是可能会导致主从数据库的数据不一致。
那么，这个主从同步和bin log我们要讲的隔离级别有啥关系呢？
有关系，而且关系很大。
因为MySQL早期只有statement这种bin log格式，这时候，如果使用提交读(Read Committed)、未提交读(Read Uncommitted)这两种隔离级别会出现问题。
比如，在MySQL官网上，有人就给官方曾经提过一个相关的Bug
这个bug的复现过程如下：
有一个数据库表t1，表中有如下两条记录：
CREATE TABLE `t1` (
`a` int(11) DEFAULT NULL,
`b` int(11) DEFAULT NULL,
KEY `a` (`a`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
insert into t1 values(10,2),(20,1);接着开始执行两个事务的写操作：
以上两个事务执行之后，数据库里面的记录会变成（11，2）和（20，2），这个发上在主库的数据变更大家都能理解。
因为事务的隔离级别是read committed，所以，事务1在更新时，只会对b=2这行加上行级锁，不会影响到事务2对b=1这行的写操作。
以上两个事务执行之后，会在bin log中记录两条记录，因为事务2先提交，所以UPDATE t1 SET b=2 where b=1;会被优先记录，然后再记录UPDATE t1 SET a=11 where b=2;（再次提醒：statement格式的bin log记录的是SQL语句的原文）
这样bin log同步到备库之后，SQL语句回放时，会先执行UPDATE t1 SET b=2 where b=1;，再执行UPDATE t1 SET a=11 where b=2;。
这时候，数据库中的数据就会变成（11，2）和（11，2）。这就导致主库和备库的数据不一致了！！！
为了避免这样的问题发生。MySQL就把数据库的默认隔离级别设置成了Repetable Read，那么，Repetable Read的隔离级别下是如何解决这样问题的那？
那是因为Repetable Read这种隔离级别，会在更新数据的时候不仅对更新的行加行级锁，还会增加GAP lock。上面的例子，在事务2执行的时候，因为事务1增加了GAP lock，就会导致事务执行被卡住，需要等事务1提交或者回滚后才能继续执行。
除了设置默认的隔离级别外，MySQL还禁止在使用statement格式的bin log的情况下，使用READ COMMITTED作为事务隔离级别。
一旦用户主动修改隔离级别，尝试更新时，会报错：
ERROR 1598 (HY000): Binary logging not possible. Message: Transaction level 'READ-COMMITTED' in InnoDB is not safe for binlog mode 'STATEMENT'小结
所以，为什么MySQL选择RR作为默认的数据库隔离级别，其实就是为了兼容历史上的那种statement格式的bin log。
那么，为啥阿里要把这个数据库隔离级别修改成 RC 呢，背后有什么思考吗？
RR 和 RC 的区别
想要搞清楚这个问题，我们需要先弄清楚 RR 和 RC 的区别，分析下各自的优缺点。
一致性读
一致性读，又称为快照读。快照即当前行数据之前的历史版本。快照读就是使用快照信息显示基于某个时间点的查询结果，而不考虑与此同时运行的其他事务所执行的更改。
在MySQL 中，只有READ COMMITTED 和 REPEATABLE READ这两种事务隔离级别才会使用一致性读。
在 RC 中，每次读取都会重新生成一个快照，总是读取行的最新版本。
在 RR 中，快照会在事务中第一次SELECT语句执行时生成，只有在本事务中对数据进行更改才会更新快照。
在数据库的 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；这时就会互相等待对方释放锁，就导致了死锁。
总结
MySQL数据库的 RR 和 RC 两种事务隔离级别，主要在加锁机制、主从同步以及一致性读方面存在一些差异。
而很多大厂，为了提升并发度和降低死锁发生的概率，会把数据库的隔离级别从默认的 RR 调整成 RC。
当然，这样做也不是完全没有问题，首先使用 RC 之后，就需要自己解决幻读的问题，这个很多时候幻读问题其实是可以忽略的，或者可以用其他手段解决。
还有就是使用 RC 的时候，不能使用statement格式的 binlog，这种影响其实可以忽略不计了，因为MySQL是在5.1.5版本开始支持row的、在5.1.8版本中开始支持mixed，后面这两种可以代替 statement格式。
那么我们回答了以下问题，
1、RR和RC到底有什么区别？RR是如何解决不可重复读问题的？
2、既然MySQL数据库默认选择了RR，那么，为啥大的互联网公司会把默认的隔离级别改成RC？
然而你或许还会有以下问题：
1、row格式和statement有什么区别？使用row的情况下，可以使用RR吗？
2、文中提到的RC的GAP lock到底是什么？Next-key Lock
数据库使用锁是为了支持更好的并发，提供数据的完整性和一致性。InnoDB是一个支持行锁的存储引擎，锁的类型有：共享锁（S）、排他锁（X）、意向共享（IS）、意向排他（IX）。为了提供更好的并发，InnoDB提供了非锁定读：不需要等待访问行上的锁释放，读取行的一个快照。该方法是通过InnoDB的一个特性：MVCC来实现的。
InnoDB有三种行锁的算法：
1，Record Lock：单个行记录上的锁。
2，Gap Lock：间隙锁，锁定一个范围，但不包括记录本身。GAP锁的目的，是为了防止同一事务的两次当前读，出现幻读的情况。
3，Next-Key Lock：1+2，锁定一个范围，并且锁定记录本身。对于行的查询，都是采用该方法，主要目的是解决幻读的问题。
mysql binlog的三种格式简单概括总结
1、三种格式：row、statement、mixed
2、区别：row格式文件比较大，statement比较小，row格式保存的是一行一行的数据，statement保存的是sql语句，mixed格式介于二者之间，statement容易丢数据，row格式则不会
3、statement容易丢数据原因是，有时候，SQL语句里面会用到一些函数，比如说取当前日期的函数sysdate，你要是用statement，binlog里同步过去的就是这个带有函数的SQL语句，而主库的当前日期，和binlog同步到slave上的当前日期，肯定是有差异的，这样两条数据就不一致了，所以这样同步的数据，就会有问题
4、row是直接把表插入到备份库中，statement是导出主库语句后，导入到备份库中，存在时间差。
每种格式的概括
STATEMENT
记录的是执行的SQL语句
优点:
日志记录量相对较小, 节约磁盘及网络IO
缺点:
可能造成MySQL复制的主备服务器数据不一致
必须记录上下文信息, 以保证语句在从服务器上执行结果相同
对于特定函数如 UUID(), user() 这种非确定性函数是无法正确复制
ROW
记录的是每一行数据的修改, MySQL5.7+的默认ROW格式.
优点:
可以避免MySQL复制中出现主从不一致的问题
对每一行数据的修改比STATEMENT模式高效
可在误删改数据后, 同时无备份可以恢复时, 通过分析binlog日志进行反向处理达到恢复数据目的
缺点:
由于记录每一行数据的修改, 所以日志量比较大
可通过binlog_row_image=FULL | MINIMAL | NOBLOB 设置日志记录的方式.
FULL: 记录行中所有列修改前后的数据.
MINIMAL: 记录行中所有列修改前的数据+被修改列修改后的数据.
NOBLOB: 记录行中所有列修改前的数据+(未对行中TEXT和BLOB类型列修改时, 记录TEXT和BLOB类型以外的列的数据.)
MIXED
混合STATEMENT和ROW两种格式, MySQL会根据执行的SQL语句自动选择.
一般的复制使用STATEMENT格式，对于STATEMENT格式无法复制的操作使用ROW格式.
如何选择binlog日志格式?
在同一个IDC机房中, 建议使用MIXED或ROW格式, 当使用ROW格式时, 建议设置binlog_row_image=MINIMAL
关于以上几个问题，你对哪个更感兴趣呢？
talk is easy, show me the code