为什么 MySQL 选择 Repeatable Read 作为默认隔离级别

桃扇骨 2024-02-20 10:56 40阅读 0赞

为什么 MySQL 选择 Repeatable Read 作为默认隔离级别？

![在这里插入图片描述][2c6893ebd73d4e9ea00545826c75f910.png]  
我们知道，ANSI/ISO SQL-92 标准定义了 4 种隔离级别，从低到高依次为：  
读未提交(Read Uncommitted)、读已提交(Read Committed)、可重复读(Repeatable Reads)、序列化(Serializable)。

> 在 RU 级别下，可能会出现脏读、幻读、不可重复读等问题。  
> 在 RC 级别下，解决了脏读的问题，但仍存在幻读、不可重复读的问题。  
> 在 RR 级别下，解决了脏读和不可重复读的问题，但仍存在幻读的问题。  
> 在 Serializable 隔离级别下，解决了脏读、幻读、不可重复读全部问题。

然而，Oracle数据库只支持 Serializable 和 Read Committed 。  
需要注意的是，**Oracle的默认隔离级别是RC，而MySQL的默认隔离级别是RR**。  
那么，你知道为什么Oracle选择RC作为默认级别，而MySQL选择RR作为默认的隔离级别吗？

Oracle 的隔离级别

前面我们提到过，Oracle只支持ANSI/ISO SQL定义的Serializable和Read Committed隔离级别。

但实际上，根据Oracle官方文档的介绍，Oracle支持三种隔离级别：Read Committed、Serializable 和 Read-Only。  
![在这里插入图片描述][580b9ca7173a40fd8c3c1ace72a8ca4b.png]  
官网链接：

https://docs.oracle.com/cd/E11882_01/server.112/e40540/consist.htm#CNCPT621

Read-Only 隔离级别类似于序列化隔离级别，但只读事务甚至不允许在事务中进行数据修改。

因此，在这三种隔离级别中，Serializable 和 Read-Only 显然都不适合作为默认隔离级别，Oracle 只剩下 Read Committed 这个选择。

### MySQL 的隔离级别 ###

MySQL 默认使用RR（可重复读）隔离级别的原因是基于历史和技术考虑。

MySQL 主从复制是通过 binlog 日志进行数据同步的，而早期的版本中 binlog 记录的是SQL语句的原文。  
![在这里插入图片描述][068034693a5a422484753bd354418aeb.png]

而早期的版本的 statement 格式下，记录到 binlog 里的是SQL语句原文，因此可能会出现这样一种情况：

例如这样一条SQL语句：  
![在这里插入图片描述][2ed65542d3934ba4b972bf8ce1c3b432.png]  
在主库执行这条 SQL 语句的时候，用的是索引 a；而在备库执行这条 SQL 语句的时候，却使用了索引 b。

【MySQL 执行优化器会进行采样预估，在不同的MySQL库里，采样计算出来的预估结果不一样，会影响优化器的判断，由于优化器会进行成本分析，可能最终选择的索引不一样。】

而又因为这条 delete 语句带了 limit，很可能会出现主备数据不一致的情况。

因此，MySQL 认为这样写是有风险的。

另外，如果使用读已提交（Read Committed）或读未提交（Read Uncommitted）这两种隔离级别，是不会添加 Gap Lock 间隙锁的。

而主从复制过程中出现的事务乱序的问题，更加容易导致备库在SQL回滚之后与主库内容不一致。

为了解决这个问题，MySQL选择了可重复读（Repeatable Read）隔离级别作为默认选项。

可重复读隔离级别，在更新数据时会增加记录锁和间隙锁，可以避免事务乱序导致的数据不一致问题。

![在这里插入图片描述][f9a79b2def7b4080a011c08e165259ac.png]  
除了设置默认的隔离级别外，MySQL还禁止在使用 statement 格式的 bin log 情况下，使用 READ COMMITTED 作为事务隔离级别。  
一旦用户主动修改隔离级别，尝试更新时，会报错：  
![在这里插入图片描述][aa2e897766764a22a0d3861d8ff1417e.png]  
所以，现在我们知道了，为什么MySQL选择RR作为默认的数据库隔离级别了  
其实就是为了兼容历史上的那种 statement 格式的bin log，解决主从复制过程中的数据一致性问题。

### 为什么默认 RR，大厂要改成 RC？ ###

尽管 MySQL 默认使用 RR 隔离级别，是为了解决主从复制过程中的数据一致性问题，但在实际应用中，根据具体需求和性能考虑，可以选择适合的隔离级别。

对于「读已提交」和「可重复读」两种隔离级别的事务来说，它们都是通过 Read View 来实现的。  
它们的区别在于创建 Read View 的时机不同：  
RC「读已提交」隔离级别是在每个 select 查询时都会生成一个新的 Read View。  
这意味着，如果在事务期间的多次读取同一条数据，前后两次读的数据可能会出现不一致的情况，因为可能这期间另外一个事务修改了该记录，并提交了事务。  
RR「可重复读」隔离级别是在启动事务时生成一个 Read View，然后在整个事务期间都使用这个 Read View。  
这样就保证了在事务期间读到的数据都是事务启动前的记录。  
![在这里插入图片描述][17a956a581ab4b6cad2e1323d5502e0d.png]  
一些大型互联网公司，如阿里等会根据自身需求，将数据库的隔离级别从默认的 RR 调整为 RC（读已提交）。

这是因为 RC 隔离级别可以提供更高的并发度和降低死锁发生的概率。

对于互联网公司来说最重要的是什么？  
当然是，高并发！

RC 隔离级别在一致性读方面比 RR 更加灵活。  
在 RC 隔离级别下，每次读取都会重新生成一个快照，总是读取行的最新版本。  
这意味着 RC 隔离级别可以提供更高的并发度，允许读取其他事务已提交的数据，从而减少了锁的竞争和等待时间。  
这对于互联网公司来说，特别是在高并发的场景下，可以提升系统的性能和响应速度。

![在这里插入图片描述][602293db5b50423db9ce36ffdff37673.png]  
其次，RC隔离级别可以降低死锁的发生概率。  
在 RR 隔离级别下，由于锁的范围更广，可能会导致更多的锁竞争和死锁情况。  
而在 RC 隔离级别下，由于只对已提交的数据进行读取，锁的范围更小，减少了死锁的可能性。  
此外，RC隔离级别相对于RR隔离级别来说，对于一些特定的业务场景更加适用。  
例如，对于一些需要实时数据的应用，RC 隔离级别可以提供更及时的数据更新，满足业务需求。  
然而，RC 隔离级别仍然存在幻读和不可重复读的问题。就需要自己解决了。

而且，很多时候，不可重复读问题其实是可以忽略的。

比如，读取到别的事务修改的值，其实问题不太大的，只要修改的时候的不基于错误数据就可以了。

所以，我们都会在核心表中增加乐观锁标记，更新的时候都要带上锁标记，进行乐观锁更新。

![在这里插入图片描述][bfc9ef1e6b394268bad7516c67d80807.png]  
总结起来，MySQL 默认使用 RR 隔离级别是为了解决，主从复制过程中的数据一致性问题，但在实际应用中，需要根据具体需求和性能考虑，可以选择适合的隔离级别。

[2c6893ebd73d4e9ea00545826c75f910.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/483c5364dc304d8cae7df6becd352c2d.png
[580b9ca7173a40fd8c3c1ace72a8ca4b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/305a5930cefd4f058b6dcafe9c3d479a.png
[068034693a5a422484753bd354418aeb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/b3f5ab2597ea4664b4939a70df8c09cc.png
[2ed65542d3934ba4b972bf8ce1c3b432.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/184c20e6d84943edad3787dc0185622a.png
[f9a79b2def7b4080a011c08e165259ac.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/25e389da3f2c4cbe8e99b003f6519943.png
[aa2e897766764a22a0d3861d8ff1417e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/e058144bd5dd45c58ecc2cca4772ff50.png
[17a956a581ab4b6cad2e1323d5502e0d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/1929d3cc6a044ab0bdac0ee952caa14c.png
[602293db5b50423db9ce36ffdff37673.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/afa9d3e4c6c14c54878cb1ccca937f95.png
[bfc9ef1e6b394268bad7516c67d80807.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/809384f0b2ee4ece8c542d9cf121ab19.png